- User Since
- Apr 18 2018, 2:22 AM (39 w, 5 d)
Wed, Jan 16
Thanks a bunch for fixing this Fangrui!
Tue, Jan 15
Mon, Jan 14
Hi Ilya, I got here from reading your other patch (https://reviews.llvm.org/D56611). I'm wondering if we could make those range utility functions more understandable.
Hi Ilya, this seems really useful for people learning how to implement their custom actions!
Thu, Jan 10
Hi Erik, this looks neat!
Wed, Jan 9
Fixed the synchronous handling of events.
Tue, Jan 8
added one more assert
Thu, Jan 3
I was thinking the same (that we might be able to make the detection more precise) but I got the impression these cases are handled later (L524 and below).
@hokein I think you are correct. I meant that it would be possible to make LSP more generic by using trigger strings instead of trigger characters..
@ilya-biryukov Yes, that's true. I would still expect some performance gain in more restrictive filtering on client's side - not sure how big though. Anyway, seems like LSP folks think character + trigger context is good enough. For example here:
Hi Alex, thanks for fixing this.
Wed, Jan 2
This looks like a work around LSP imperfection indeed.
Dec 5 2018
Nov 29 2018
Since AFAIK Sam is off until the end of the year I am adding more reviewers.
Addressed most of the comments.
Nov 28 2018
Nov 27 2018
Going to split SymbolID.h as a NFC commit per Alex's suggestion and land this.
Finished tests and fixed operator<<(SymbolDetails) for containerNames that aren't part of fully qualified name.
Morphed into https://reviews.llvm.org/D54799
Nov 26 2018
Adressed last comments + initial unit tests.
Removed empty line noise and fixed doxygen annotation.
Addressed comments from the reivew.
Thank you very much for the review Sam!
Hi @hokein, I am just keeping up to date with changes.
Nov 23 2018
Multiple symbols per location.
Couple minor changes based on discussion.
- Move SymbolID to index/SymbolID.h.
- Rename in ClangdServer - drop the verb from method name.
- Remove conditional return in XRefs.cpp.
I am just wondering if it make sense to include any symbol with empty name, empty USR and no ID in LSP response. I assume either clangd or our LSP client (and hypothetically others too) will have to filter these out. But it might violate consistency with other LSP methods. Anyway, if we agree on filtering such symbols either in getSymbolInfo() or ClangdServer::getSymbolInfo() I am happy to do it, if not it's fine with me.
Nov 22 2018
Changes based on review.
Nov 21 2018
Nov 19 2018
Hi Kadir, I have one small nit otherwise LGTM.
Nov 16 2018
LGTM. Thanks for the patch!
Could you please add a test? I'd suggest minimizing the testcase you linked and placing it to clang/test.
Nov 15 2018
This looks reasonable to me but asked people with more context to take a look.
Nov 14 2018
Correction - I asked offline about our intended use of USR in LSP and it seems we might want to receive it as part of other responses too. Nothing specific for now but it's probable that it won't be just this singular case.
We are also discussing creating separate method as we'll likely want to add other data to the response in the future. Would you prefer USR not to be in the standard part of LSP but only in our extension?
One more thing - shall I create new client capability flag for this?
Nov 12 2018
Nov 7 2018
Rewritten tests to shared implementation different cases.
LGTM Thanks for fixing this!
LGTM and it seems like all of Eric's comments were answered too.
Nov 6 2018
I tried to move the getNearestOption() to it's only client - EmitUnknownDiagWarning() but it turned out to be a significant change because of clang/Basic/DiagnosticGroups.inc use in DiagnosticIDs.cpp.
I suggest we leave that for eventual future refactoring since it would blow up scope of this patch a lot.
Oct 15 2018
Sep 26 2018
Sep 25 2018
Sep 21 2018
Allright, I will remove destructor from clangd completion results which solves this particular issue.
Sep 20 2018
Sorry my bad. You are right, we aren't showing destructors in clangd for normal classes. The case where I noticed is kind of a corner case with template class.
You might be right - I am assuming here that we want consistent behaviour between constructors and destructors.
Sep 17 2018
Hi Volodymyr, do you think you might take another look?
Sep 12 2018
I got some test failure with the patch, still investigating the issue.
Sep 10 2018
I tried to come up with some input that breaks current implementation so I could add the test. Problem is that invalid memory read doesn't guarantee deterministic crash.
E. g. with this input the current implementation is definitely reading way past the buffer:
SmallVector<char, 1> IgnoreMe; const char* Foo = "foo%"; const char* FooEnd = Foo + 4; Diag.FormatDiagnostic(Foo, FooEnd, IgnoreMe);
Thanks for the feedback - interesting points!
Sorry for the delay - I was busy with other things for past two weeks.
Aug 31 2018
Aug 30 2018
Aug 16 2018
Oh, I thought that what everyone wanted was test-specific behaviour. I like both approaches you propose much more!
If we go for the generic option we can effectively start "checking stderr" in tests by using the flag. That would be nice.
Hi Alex, nice work!
Adding Volodymyr who landed related patch recently.
Aug 15 2018
Aug 14 2018
I can see the value of getting more information in case of unexpected test behaviour but I still don't really like to have separate codepath for testing purposes.
I think that by introducing different codepath for testing purposes we might end up with fewer bugs in tests but the actual production code could become less tested. Actually, even the -lit-test itself might be not the theoretically most correct approach but I do see the practical reason for it. In general I'd rather keep the testing specific code to a minimum though.
Aug 13 2018
Aug 10 2018
Aug 8 2018
Hi Greg, this looks interesting! I got curious about your patch since I am dealing with another protocol from the same "family" - LSP.