[PATCH] D110216: [clang] retain type sugar in auto / template argument deduction

Matheus Izvekov via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Sep 23 15:57:38 PDT 2021


mizvekov added inline comments.


================
Comment at: clang-tools-extra/clangd/XRefs.cpp:495
+                                               const QualType &Type,
+                                               bool Underlying = false) {
   const auto &SM = AST.getSourceManager();
----------------
sammccall wrote:
> (i'm confused by the optional parameter - there's only one caller)
Oh I must have just assumed there were other callers, will fix.


================
Comment at: clang-tools-extra/clangd/XRefs.cpp:506
+      targetDecl(DynTypedNode::create(Type.getNonReferenceType()),
+                 DeclRelation::TemplatePattern | DeclRelation::Alias |
+                     (Underlying ? DeclRelation::Underlying : DeclRelation()),
----------------
sammccall wrote:
> `Alias | Underlying` means that go-to-definition will return both A and B in this case:
> 
> ```
> using A = int;
> using B = A;
> au^to x = B();
> ```
> 
> I don't think we particularly want that.
> 
> Really this change is just trying to make sure we can resolve `decltype(auto) -> decltype(foo) -> Foo` right? I think we should rather make clangd::getDeducedType(...) unwrap the decltype(foo) in the first place.
I think that one is to make sure we can look through extra DeducedType sugar when finding some definition.
Specifically a case like the 'auto on lamda' from XRefsTests:
```
        auto x = [[[]]]{};
        ^auto y = x;
```
`y` will have an extra layer of AutoType sugar there, since it deduced from something which already had AutoType sugar.

But maybe the way I implemented that in clangd is not good. I will take a look again, thanks for the explanation.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D110216/new/

https://reviews.llvm.org/D110216



More information about the cfe-commits mailing list