sammccall added a comment.

I'm missing some context on this patch. My intuition is that constrained auto 
is unlikely to be used in deducible contexts, but maybe some people will like 
`Iterator<int> auto I = foo.begin()` or so...



================
Comment at: clang-tools-extra/clangd/refactor/tweaks/ExpandAutoType.cpp:99
       if (const AutoTypeLoc Result = TypeNode->getAs<AutoTypeLoc>()) {
-        if (!isStructuredBindingType(Node) &&
+        if (!isStructuredBindingType(Node) && !Result.isConstrained() &&
             !isDeducedAsLambda(Node, Result.getBeginLoc()) &&
----------------
Why? Is there a mechanical limitation (bad typeloc or so) or is this a policy 
decision?

If it's technical, we should link to a bug


================
Comment at: clang-tools-extra/clangd/unittests/tweaks/ExpandAutoTypeTests.cpp:88
+      R"cpp(template <typename T> concept C = true;
+^C a^uto abc();
+    )cpp");
----------------
This shouldn't be unavailable because it's constrained, it should be 
unavailable because it's not deduced.

Does this case pass or fail today?

If the issue with constrained auto is syntactic, can you add a deductible test 
case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D117463

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to