Conversation
|
Thanks for the patch, I feel like this isn't a "useful" extension nowadays as we've improved both picking up compile flags dynamically and also are keeping better track of preamble valid-ness. Any specific motivation for the patch, apart from increasing docs coverage? @sam-mccall were there any other historical use cases for this extension that might still be relevant? maybe we can just retire it going forward in clangd. |
I believe this is being used by clangd users at Ericsson, with a modified vscode client. The use case is a client-side action that creates a header file for which an #include was present (and unresolved due to the file not yet existing) in an open source file. Sending a Please do not remove the feature :) |
Ok but I think that's exactly the improvement I mentioned above. If they were to send a didChange, even without forceRebuild set, clangd should still rebuild that preamble nowadays. |
Oh, interesting! Let me follow up on this; will change the PR to draft for now. |
kadircet
left a comment
There was a problem hiding this comment.
argh, now i see why the confusion in the main thread occured. I wrote this comment but forgot to hit submit :( still getting used to the PR workflow..
|
|
||
| Clangd makes an effort to invalidate ASTs when dependent files change, but | ||
| there are some changes it does not detect, for example when an unresolved | ||
| include becomes resolved because the header file has been created. |
There was a problem hiding this comment.
well that isn't strictly true nowadays, we actually do track missing include directives when building a preamble and will invalidate the preamble if any of them become available.
the only scenario that I can think of for forceBuild to be useful nowadays is, when foo.h becomes available in an earlier include search path than it was found before.
No description provided.