- User Since
- Aug 28 2018, 2:16 AM (63 w, 6 d)
Fri, Nov 15
Minor change: Resued variable.
Modified tests for better error messages.
Uploading latest patch
Thu, Nov 14
Tue, Nov 12
Added tests for CollectMacros.h
Mon, Nov 11
Fri, Nov 8
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.
Thu, Nov 7
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.
Thu, Oct 31
Tue, Oct 29
Oct 18 2019
Added additional tests.
Oct 16 2019
Oct 9 2019
Make action unavailable if the namespace contains a using namespace decl.
Oct 8 2019
Oct 7 2019
Make the tweak trigger only for TopLevelDecl.
Addressed comments and fixed build failure.
Revert unintended formatting.
Sep 24 2019
Removed ununsed header.
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).
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.
Added client/server capabilities.
Made lit test smaller.
Sep 18 2019
Fixed error message.
Sep 17 2019
Sep 16 2019
Sep 13 2019
Remove extraneous namespace comment.
Sep 9 2019
Create range only if it represents a valid file range.
Removed logs for debugging.
Aug 7 2019
Formatted new test.
Added tests in CodeCompletionStringsTests.cpp
Removed unused include of logger.
Feb 18 2019
Sep 28 2018
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.
Sep 27 2018
Sep 4 2018
I don't have commit access. Can you please submit this ?
- fixed the style issues
Sep 3 2018
- applied changes
Applied the changes suggested.
- Moved helper function into anonymous namespace
- applied suggested changes
Applied suggested changes.
Aug 31 2018
Made the suggested changes.
- Made suggested changes.
Aug 30 2018
- Moved Stat to the subclasses of InMemoryNode