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
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
