[PATCH] D154853: [clangd][c++20]Consider the constraint of a constrained auto in FindTarget.

[Nathan Ridge via Phabricator via cfe-commits]

nridge added inline comments.


================
Comment at: clang-tools-extra/clangd/unittests/FindTargetTests.cpp:581
+
+    [[Fooable]] auto i = 42;
+  )cpp";
----------------
nridge wrote:
> sammccall wrote:
> > this is going to have the same behavior on the `auto` token, right?
> > 
> > This is my main practical concern, that go-to-definition, hover, find-refs, go-to-type etc on `auto` will now treat `Fooable` as their target.
> > 
> > (That said, I'm not sure exactly how common it is for `auto` to be constrained in a non-dependent context...)
> > That said, I'm not sure exactly how common it is for `auto` to be constrained in a non-dependent context...
> 
> I think it may be reasonably common. For example, in this [hello world example](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2300r7.html#example-hello-world) for the C++23 asynchronous programming proposal we have things like `scheduler auto` and `sender auto` (where `scheduler` and `sender` are concepts).
> 
> So, do think we want `auto` linked to the concrete deduced type in situations like this, and only the concept name linked to the concept definition.
> in this [hello world example](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2300r7.html#example-hello-world) for the C++23 asynchronous programming proposal

(Slight correction: this is a C++26 proposal. My point remains though.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D154853