I can only refer to my last comment, even in latest trunk that code is still active for the codegen passes.
But meanwhile I found the corresponding new code.

Well last time I checked it this code was still in use. When is it going to be deleted?
Also the test has value to ensure the new pass manager emits these entries as before.

Yeah it was conscious at least. No strong opinion on that though.

Yeah quite complex: https://godbolt.org/z/8T5Pqadro

Thanks, it seems to fix the base case, but I still see multiple lenses when I add

One remaining issue is multiple lenses for template code like

Thanks could you also commit it?

I only came across it when testing a PCH build.
https://github.com/Trass3r/llvm-project/actions/runs/3423679621/jobs/5702548183

Warning: <built-in>(1,9): warning: definition of macro '_GNU_SOURCE' does not match definition in precompiled header [-Wclang-cl-pch]

It was set for clang but not for llvm when building with clang-cl.

rebase

fix build

fix build error

More of an RFC.
See https://github.com/llvm/llvm-project/issues/57525.
This marks some of the classes with devirtualization potential final, as reported by gcc.
It needs to be checked which of those make sense.
Also, is there a proper way to mark classes as 'explicitly designed to be subclassed' (along the lines of class F /*non-final*/ : ...?).

RFC. First described in https://github.com/clangd/clangd/issues/1326.

Thanks, could you also commit it? I don't have the rights.

add fallback DisplayString for ArrayRef

add this-> to make it clear

change SDNode DisplayString

remove bases codelens for classes
fix lit test
exclude self from ref count

remove duplicate APInt
update SmallVector

@MaskRay ping

@thakis ping

Thanks for this!
When I experimented with this for #42754 I also came across functions like
Expr::isConstantInitializer
ExprConstant.cpp HandleFunctionCall/HandleConstructorCall
ByteCodeEmitter::compileFunc

Thanks, could you also commit it? I don't have the rights.

It looks like this:

In D135690#3862112, @aaron.ballman wrote:

Pretty sure that was after /Zc:inline (IIRC that existed in MSVC 2015 which was roughly when I recall we were hitting this).

https://llvm.org/docs/DeveloperPolicy.html#obtaining-commit-access

In D135690#3858541, @aaron.ballman wrote:

In D135690#3856863, @Trass3r wrote:

Didn't realize it has a big cost. Looking inside the AST_MATCHER and REGISTER_MATCHER macros I can't see any unique instantiations, should be memoized?

IIRC, the cost may depend on the compiler. I know we had to enable /bigobj when building with MSVC because each template instantiation here was being added to its own section in the object file and we'd wind up with tens of thousands of sections.

In D135690#3852362, @aaron.ballman wrote:

what's the need for adding this matcher? Do you plan to use it for some in-tree needs? We usually only add new matchers where there's an immediate need for them because of how expensive AST matchers are to compile (and each matcher adds a fair number of template instantiations to the final binary as well, so there's a bit of runtime cost too).

@MaskRay Thanks! Could you commit it for me?

@thakis found a suitable test where I could add this

rebased

Any pointers where that test would go and how to write it?

@curdeius I built these up over time and would like to upstream them.
Some of them may be out of date now and some things were tricky like the Uses/User stuff so I could use some feedback in general to polish it.

explicit lambda capture and format

I don't know, are there any tests for all the other scopes?
There is a generic test for the functionality.

Whenever I tried this option in the past it crashed clangd.
I recommend doing some more testing before flipping the switch.

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 featured here. Though looks like the test got dropped.

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?