In D130689#3707296, @mehdi_amini wrote:

land the change, wait for a couple of hours to ensure that all bots have picked up the revision, then revert

Also fails on gcc 11.2: https://github.com/Trass3r/llvm-project/runs/7703302032

I just searched again and found https://reviews.llvm.org/D91930.
But seems like it never got updated with the latest code contained in here.

That's the general approach for clang-tidy use too, rely on clang-format for formatting the fixes.

Hmm just a few curious questions from the sidelines.
Why a "custom system" instead of something -ftime-trace based?
How much overhead does this introduce, esp. for normal use-cases?
What's the gain? The information is very coarse and general-purpose system profiling tools should give you much better information regarding file system perf.

@sammccall pls merge

In D120258#3340717, @sammccall wrote:

(I think this patch is good to go now, ready for a stamp if anyone agrees :-)).

In D120258#3340357, @sammccall wrote:

I'll just suppress the hint here, ParamVarDecl::getLocation() appears to incorrectly point at the rparen and it's not obvious what we're hinting without a name in any case.

For a callback like

[](auto) {...}

the inlay hint is displayed after the ).
Which also looks confusingly like a hint for the lambda return type (which isn't implemented yet afaik).

I don't have a good sense for how common the "multiple instantiations, same type" scenario is; perhaps @Trass3r has an opinion on that.

No apparent differences. Is there a way to automatically reduce it?

Looks like this only covers a subset.
I see hints for some generic lambdas but not for others while hovering over auto reveals the type.

Is it intentional that the resolved type is not shown in the variable hover (I guess, looking at the code):

param payload
Type: const auto &

In D52296#1285328, @grimar wrote:

In D52296#1284130, @probinson wrote:

Only DWARF supports this, correct?

I am not aware of any kind of debug information splitting except DWARF splitting.

Has this ever gotten anywhere?
I think the correct mapping would be something like -fno-ms-compatibility -fno-delayed-template-parsing, not sure about -fms-volatile -fms-extensions. Edit: Actually no, you need the extensions and disabling compat makes it disguise as gcc. So only the template parsing is left.

Simply didn't look for other uses of IntShift :)
I'm currently not working on llvm but I still have a bunch of half-decent visualizers for llvm::Value types and the like.

Is this still in progress?