[PATCH] D62814: [clangd] Treat lambdas as functions when preparing hover response

Sam McCall via cfe-commits cfe-commits at lists.llvm.org
Tue Jun 4 08:08:37 PDT 2019


AST dump doesn't traverse into typelocs, which is where x is.

That said, this particular case is not worth any complexity at all. Even
pointer-to-lambda is vanishingly rare.

Regarding dropping ref/pointer info: one option here is keeping the old
"class (lambda)&", and simply making sure we now populate return/params.
I'm not sure setting Type as if it were a function is actually clarifying.

If you don't want to do this, I'd suggest not unwrapping pointers, and
living with the lost ref qualifiers (only realistic case i can think of
where it matters is a by-ref capture of a lambda inside another lambda, and
i don't think anyone will notice if we pretend it's a value)

On Tue, Jun 4, 2019, 16:11 Kadir Cetinkaya via Phabricator <
reviews at reviews.llvm.org> wrote:

> kadircet added inline comments.
>
>
> ================
> Comment at: clang-tools-extra/clangd/unittests/XRefsTests.cpp:831
> +         };
>           return HI;
>         }},
> ----------------
> ilya-biryukov wrote:
> > kadircet wrote:
> > > ilya-biryukov wrote:
> > > > Could you add another test with even weirder types where we fail to
> show the signature? To make sure we don't break when reaching the
> limitations of the chosen approach and document what those limitations are.
> > > >
> > > > Something like:
> > > > ```
> > > > auto a = [](int a) { return 10; };
> > > > auto *b = &a;
> > > > auto *c = &b;
> > > > ```
> > > >
> > > > We would fail to show the signature here, but it's totally ok to
> ignore it.
> > > added cases, and changed code(a lot simpler now) to generate
> signatures for those cases as well.
> > Here's an example when the new approach falls short too:
> >
> > ```
> > auto a = [](int) { return 10; }
> > std::function<void(decltype(a) x)> b;
> > ```
> >
> > In general, are we ok with loosing all the information about the type
> that we drop?
> > One level of references and pointers seemed ok, dropping more is a bit
> more cheesy..
> >
> > At the same time, either case is **so** rare that we probably don't care.
> are you talking about hovering over `x` ? I don't think AST contains
> information regarding that one.
>
> for a code like this:
> ```
> auto foo = []() { return 5; };
>
> template <class T>
> class Cls {};
>
> Cls<void(decltype(foo) bar)> X;
> ```
>
> This is the AST dump for variable X:
> ```
> `-VarDecl 0x2b0e808 <line:6:1, col:30> col:30 X 'Cls<void
> (decltype(foo))>':'Cls<void ((lambda at a.cc:1:12))>' callinit
>   `-CXXConstructExpr 0x2b12e80 <col:30> 'Cls<void
> (decltype(foo))>':'Cls<void ((lambda at a.cc:1:12))>' 'void () noexcept'
> ```
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D62814/new/
>
> https://reviews.llvm.org/D62814
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20190604/00f7eb6d/attachment-0001.html>


More information about the cfe-commits mailing list