This seems right for consistency with SemanticHighlights.

In D116786#3257932, @kadircet wrote:

Any ideas? :-(

I've got a feeling that, this should also be annoying in the case of function calls (especially when there's only one overload)? Maybe we should just debounce the inlayhint requests (by saying contents modified to the clients)?

This looks good now, only blocker is dropping the change to LookupFile somehow.

In D116786#3247800, @kadircet wrote:

a drive by concern around possible flakiness of the interaction. have you checked how does it look like when the user is still forming the initializer? it might be annoying if their cursor kept jumping around while they're editing the (possibly half-formed) initializer.

Address comments, rebase.
This category is *off* by default.

Thanks!

Happy to take a look at this, but is there a particular motive for optimizing this?
Looking at some profiles this appears to be something like 0.1-0.5ms in fairly complex configurations.

Nice!

Nice!

@kadircet What we forgot to think about here is that this allows more semantic checks to happen at template parsing time, which affects diagnostics.

Thanks!

This puts the relative path v1 on the include path (it's a fancy -I v1).
In case of compile_flags.txt, the working directory is the dir containing compile_flags.txt.
So if this is to be placed somewhere other than the parent of the v1 header directory, it will need to be some other (relative or absolute) path to that directory.

Ah, this seems to be coming from the buildbot configuration.

This appears to have triggered some buildbot failures:

I'm missing some context on this patch. My intuition is that constrained auto is unlikely to be used in deducible contexts, but maybe some people will like Iterator<int> auto I = foo.begin() or so...

In D95046#3247844, @njames93 wrote:

In D95046#3247793, @sammccall wrote:

Sorry about letting this sit. I think this is good to go, with a naming tweak.

For the 14 cycle, it should be hidden: we may want to tweak the interactions with didSave reparsing etc, and there may be other unexpected wrinkles.

Regarding moving to config: we should do this, but there's some dumb bikeshedding of names (mostly: does this go at the top level or do we want a Parsing block or something, will other things fit in there, etc). So a hidden flag seems like the easiest thing for now.

I've been using this locally for months. The one nit i have is if you edit a header file then switch to a different file, diagnostics aren't updated until you force clangd to reparse the file (by editing it for example).

Sorry about letting this sit. I think this is good to go, with a naming tweak.

This isn't an ideal fix but it's simple, we know the real fix is invasive, and 14 is upon us.

In D117268#3244971, @ldionne wrote:

@sammccall Do you know whether clang-tidy can use compile_flags.txt? If it did, that could perhaps solve both this issue and also https://github.com/llvm/llvm-project/issues/45348.

Thanks, LG!

add test, fix build

PTAL

Handle EOF

Thanks! You caught a serious bug, I'm digging into it.

In D116925#3231110, @hokein wrote:

In D116925#3230991, @sammccall wrote:

I wasn't sure whether to suppress this in clang or clangd, wonder what you think.

I think it is fine to do it in clang. pp_pragma_once_in_main_file is a similar diag, and clang has already suppressed it.

add fixme

In D117036#3234786, @kadircet wrote:

nit: I'd rename the patch to remove rather than retire.

rename patch

Fix tests

Thanks! Much nicer :-)

Revert hover changes, only use for code complete

Rebase (offsetInSelFile)

Fix printName

Never eat malformed decl while code completing

Use the other end too

I wasn't sure whether to suppress this in clang or clangd, wonder what you think.

In D116387#3230893, @hokein wrote:

Agree that __ reserved names are ugly, but I'm not sure this is a great improvement.

I played around the patch locally, and found the new behavior being confused in some cases (mostly inconsistencies between deuglified places vs uglified places), and seems hard for readers to predict it:

Agree, but I don't think it needs to be predictable, it's enough that the output can be understood.
(e.g. I never particularly noticed *which* identifiers in stdlib were ugly, just that the thing overall was hard to read).
i.e. if we remove the underscores half the time, that seems like a win.