Added a few minor changes before committing:

• surround names of .clang-format files with double backticks
• ensure no lines are longer than 80 characters

LGTM

@sammccall, @klimek, @gribozavr2, @MyDeveloperDay who would be the best reviewer for this?
Could do the reviews myself for small CLion-related documentation changes if everyone is ok with this. Does that LG?

Fix compilation after rebase

• Rebase

As soon as I add a new enum value, this starts crashing some tests (even if we don't ever set the flag or serialize it).
Not sure what causes it and won't have time to figure it out before I leave. Sorry about that :(

Rebase on top of refactored dependence propagation

LGTM

• Fix tests

@rsmith this does not pass through testing, I've messed up somewhere while moving the code.
I'll find what went wrong and fix it tomorrow. Please tell if the approach itself LG.

LGTM!

I've opted for duplicating the common flags across all the introduced enums (contains-unexpanded-pack, instantiation-dependent) , this is somewhat ugly, but everything else is even more complicated to use.
Less enums would also be a good idea probably, see the relevant comment.

• Use different types for different AST categories
• Rename to getDependence

• Use DependencyFlags for TemplateName and NestedNameSpecifier

Maybe move this into LLVM helpers? Duplicating threading primitives sounds like a bad idea, even for tests.

• Rebase

• Rebase, get rid of accidental changes with TemplateDeclaration

The patch contains only tests, are we missing the actual functional change?

In D72498#1816424, @lh123 wrote:

Currently, I think that in most cases, showing both expanded (canonical) and spelled types is sufficient.

This has been used in ycmd for ~4 years without complaint. https://github.com/clangd/clangd/issues/58#issuecomment-507800970

• Add compound assignment operations

In D72498#1815500, @lh123 wrote:

• hover over the front , you'll see "instance-method front → std::vector<int, class std::allocator<int> >::reference".
• hover over the push_back, you'll see "std::vector<int, class std::allocator<int> >::value_type && __x".

In D72498#1814366, @sammccall wrote:

@ilya-biryukov @kadircet what do you think about unwrapping decltype only when it's a return value (optional: of a function whose leading return type is auto) to narrowly catch this idiom?

In D65591#1791876, @rsmith wrote:

@ilya-biryukov Did I forget anything?

In D72498#1813962, @sammccall wrote:

Maybe we want both the normal type and the canonical type?

Canonical types are often *really* ugly, especially with STL types (we don't have the "as written" form). And presenting the types twice might be at least as confusing/noisy as helpful. But if you have examples where this would be better, it'd be interesting.

I'm mostly trying to find a consistent rule we can apply to make these decision.
auto, decltype and typedefs are very similar in this regard, it's a bit confusing we use different rules for those. Although I can see how auto and decltype could easily be perceived differently and fall into a different group.

In D72498#1813963, @kadircet wrote:

I think typedef and decltype have different nature, the latter is a lot more obscure than the former, that was the reason why I handled decltypes specifically.

I tend to disagree here. decltype is normally the last resort, so whatever it produces is probably super-obscure, would even expect it to be not representable in C++ in many cases.
E.g.

auto Callback = []() { ... };
decltype(Callback) ^a = Callback;

In D72498#1813962, @sammccall wrote:

It's particularly unclear to me why typeprinter descends into auto but prints decltype, but Kadir says that seems to be intentional.

Also don't see why they choose to have this inconsistency and I haven't seen any indication it's not a coincidence.
@kadircet, why do you think it's intentional? Should we put some comments there?

Could it be the case that we want to show the canonical types (i.e. without all syntax sugar)?
Maybe we want both the normal type and the canonical type?

This does not work for more complicated types, though?
E.g. decltype(a+b)* a or vector<decltype(a+b)> a?

Could you also add a test (and possibly support this in the visitors) for findExplicitReferences?

LGTM

LGTM, thanks!

LGTM

• Remove debug logs
• Cosmetics

Remove the (now redundant) NodeAndRole class

Here's my attempt at storing the deduced type in TypeLocs: D72442.
It almost worked, but still needs an update to fix some test failures.

This produces the following test failures after running check-clang:

Failing Tests (4):                                                                                                                                                                                                 
    Clang :: CXX/dcl.dcl/dcl.spec/dcl.type/dcl.type.class.deduct/p1.cpp                                                                                                                                            
    Clang :: SemaCXX/cxx1z-class-template-argument-deduction.cpp                                                                                                                                                   
    Clang-Unit :: Rename/./ClangRenameTests/RenameClassTests/RenameClassTest.RenameClasses/34                                                                                                                      
    Clang-Unit :: Rename/./ClangRenameTests/RenameEnumTests/RenameEnumTest.RenameEnums/7

@rsmith, gentle ping. WDYT? Is this a step in the right direction?

I'm also looking into fixing this in clang, this shouldn't be too hard.
But please land the workaround for now.

LGTM

• Cosmetics

LGTM

In D67224#1804513, @nridge wrote:

Just throwing a wild idea out there: what if we used textDocument/onTypeFormatting to replace the . with -> as soon as it's typed?

LGTM

Please add a test for findExplicitReferences too

I landed a patch that does exactly this a few days ago:
14e11005d1a6ac1fecb230c470e9011d6956b8e4

LGTM

Would be nice to write a test too, but didn't get to it yet...

• Use DependencyFlagsBits for computing NumExprBits
• Reformat

LGTM. Do you have commit access or should we land this for you?

+1, please upload a diff with full context

Thanks for fixing this!

LGTM

Also note that this change does not move any code around to make sure this change is easy to review and validate that the code is doing the same thing.
I'm also planning to move all the code that computes dependencies into one place (it's currently scattered around many files and it certainly makes it quite hard to find bugs in the code and update it). But I would really like to get everyone aligned on the direction we're taking here.

@rsmith, could you please take a look and let me know whether you think adding a new type for this makes sense?

Thanks for the fixes!

LGTM