Addressed comments.

Minor change: Resued variable.

Modified tests for better error messages.

Uploading latest patch

Fixed typos.

Added tests for CollectMacros.h
Addressed comments.

Rebase

Removing changes from different patch.

Please ignore the changes from patch https://reviews.llvm.org/D69937
Will fix this.

Hopefully reverting unintended changes.

• [clangd] Store xref for Macros in ParsedAST.

We actually use both the name and the source location of the macro to calculate its ID.
I see that the subject of the patch might suggest otherwise.
This is a trivial change which just changes the params of the function so that users don't have to carry the IdentifierInfo when we just want the name out of it.

Addressed comments.

Addressed comments.

Addressed comments.

Added additional tests.

Addressed comments.

Added documentation.

Make action unavailable if the namespace contains a using namespace decl.

Addressed comments.

Make the tweak trigger only for TopLevelDecl.

Addressed comments and fixed build failure.

Revert unintended formatting.

Removed ununsed header.

Addressed comments.

The SelectionRangeClientCapabilities determines what should the LSP server send the client, if it is true, clangd should send SelectionRangeRegistrationOptions.
But looking at the current specification, it doesn't seem to add too much value. I think we can just simplify return a bool for now (as you did in this patch).

Addressed comments.

I am not sure adding client capability is useful here. I have not used the client capability for selectionRange anywhere and I think we can remove it.
WDYT ?

Addressed comments:
Added client/server capabilities.
Made lit test smaller.

Addressed comments.

Fixed error message.

Addressed comments.

Resolved comments.

Remove extraneous namespace comment.

Minor changes.

Addressed comments.

Create range only if it represents a valid file range.

Removed logs for debugging.

Formatted new test.

Added tests in CodeCompletionStringsTests.cpp
Resolved comments.

Removed unused include of logger.

+cc myself

it sounds like this is for record-replay.

Yes this is for record-replay purpose.

What are these files in practice?

During loading a modules the files that were required to make the module are stat()ed and their sizes are used to verify that the module is still valid. There are occurrences of more stat() only files (apart from the use in modules) which I am not aware of.

In the replayed compilation, we assume the accessed files are the same, is it safe to assume we never read files we previously stat()ed?

I would call it a requirement instead of an assumption. The replay must be exactly the same (even the file stats and reads). If Clang reads the file in replay which was only stat()ed during compilation, it indicates non-determinism or something wrong (in clang or FS).
We currently deal with such files by adding empty buffers for them based on this assumption/requirement only.

it seems like this could also be achieved with an overlayFS adding a simple specialized FS that only provides the stat-only files. If this is a relatively niche feature, cramming it into InMemoryFileSystem may not be the best option. Any thoughts on the tradeoff here?

We can reuse the InMemoryFS to make another FS which just serves stat-only files. A tradeoff I can think of is: we might need to store a random buffer of required size to make final status of the file correct.

I don't have commit access. Can you please submit this ?

• fixed the style issues

• applied changes

Applied the changes suggested.

• Moved helper function into anonymous namespace

• applied suggested changes

Applied suggested changes.

Made the suggested changes.

• Made suggested changes.

• Moved Stat to the subclasses of InMemoryNode