Sorry if I missed any important design discussions here, but wanted to clear up what information we are trying to convey to the user with the status messages?
E.g. why seeing "building preamble", "building file" or "queued" in the status bar can be useful to the user? Those messages mention internals of clangd, I'm not sure how someone unfamiliar with internals of clangd should interpret this information.
Dec 14 2018
Dec 5 2018
Nov 5 2018
I'm in yet another camp: I carefully save when I have something that is correct enough syntax, so I only want errors from with changes from the exact file I'm editing and the rest of the files in saved state.
Oct 16 2018
Oct 15 2018
Oct 12 2018
Thanks for your input. I have opened https://reviews.llvm.org/D53220, which removes that option.
Oct 4 2018
I just tried this, this looks very promising! It should help build our outline view in a much more robust way than we do currently.
So I revisited this today. In the end, restarting clangd in our IDE works well. It should be merged anytime soon:
Sep 20 2018
Ohh awesome, I didn't know the LSP supported that. I'll try it it Theia when I have time.
Sep 13 2018
If this setting exposed directly the users in Theia or is it something that is exposed via a custom UI (e.g. choosing named build configs or something similar)?
Sep 12 2018
Wow, this is getting somewhat complicated.
Have you considered rerunning clangd whenever someone changes an option like that?
Would that be much more complicated on your side?
Not opposed to having an option too, just want to be aware of the costs involved on your end.
Not sure who should review this, please feel free to add anybody who would be appropriate.
Sep 6 2018
Aug 29 2018
Aug 28 2018
Aug 27 2018
Aug 23 2018
Aug 10 2018
Looks good with a few nits. Looks like you didn't update the patch correctly. You have marked comments done, but your code doesn't get changed accordingly. Please double check with it.
I tried your patch and it did fix the duplicated issue I encountered before. Thanks for fixing it!
Aug 9 2018
Sorry for the delay. I thought there was a dependent patch of this patch, but it seems resolved, right?
A rough round of review.
Aug 8 2018
New version. I tried to share the code between this and SymbolCollector, but
didn't find a good clean way. Do you have concrete suggestions on how to do
this? Otherwise, would it be acceptable to merge it as-is?
Aug 6 2018
I see, thanks for the explanation.
LGTM for the update revision, given we have confirmation the tests pass on Windows.
Aug 5 2018
Both check-clang and check-clang-tools pass successfully for me on Windows with the patch.
Aug 3 2018
The tests now work on Windows, I added some path adjustment steps.
This revision got 'reopened' and is now in the list of accepted revision. Should we close it again?
This was not tested on windows yet.
Aug 2 2018
Capitalizing sounds nice. +1 to just do it without an option.
My favorite essay on this is
That's fine with me. I'll try it and time will tell if I like it or not :).
Aug 1 2018
Add -Wno-nonportable-include-path to test/PCH/case-insensitive-include.c
@eric_niebler, question for you:
Jul 31 2018
Address Ilya's comment (add an indirection for initializationOptions).
@simark would you mind finishing this patch and committing it? I won't be able to finish it given that I started it at a different company, etc.
Jul 26 2018
I think this addresses all of Ilya's comments.
Jul 25 2018
Thanks, that's simple and efficient. I'll update D49267 (to call reparseOpenFiles once again) once this is merged.
Fix tests on Windows
It would make it easier for your reviewers to look at the new changes if
you just reopen this patch and update the diff :)
I uploaded a new version of this patch here:
Jul 24 2018
The approach is not ideal, but may be a good middle ground before we figure out how we approach file watching in clangd. Note that there are other things that won't force the updates currently, e.g. changes to the included headers won't cause rebuilds of the source files until user modifies them. And those are much more frequent than changes to compile_commands.json, so they seem like a more pressing problem.
Jul 23 2018
Thanks for putting up this change! It can be really annoying that clangd does not pick up the compile commands that got updated.
A few things of the top of my head on why we might want to punt on using the LSP watches:
- File watching may not be implemented in the language server at all. That's certainly the case for our hacked-up ycmd<->lsp bridge.
Jul 17 2018
Jul 16 2018
Add tests for both == and !=.
In theory you'd need separate tests for op== and op!= returning false (currently all the tests would pass if both implementations returned true in all cases), but not the biggest deal.
- Add test
- Make operator== a function instead of method
- Add operator!= (so I can use EXPECT_NE in the test, and because it may be useful in general)
Any chance this can/should be unit tested? (also, in general (though might
not matter in this instance), symmetric operators like == should be
implemented as non-members (though they can still be friends and if they
are, can be defined inline in the class definition as a member could be),
so any implicit conversions apply equally to the LHS as the RHS of the
Jul 12 2018
Remove unintended changes
Note, D49265 in clang is a prerequisite.
- [clangd] JSONTracer: flush after writing event