[clang] [Clang] prevent recovery call expression from proceeding with explicit attributes and undeclared templates (PR #107786)
Oleksandr T. via cfe-commits
cfe-commits at lists.llvm.org
Mon Sep 23 12:33:17 PDT 2024
================
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++20 %s
+
+namespace GH49093 {
+ class B {
+ public:
+ static int a() { return 0; } // expected-note {{member is declared here}}
+ decltype(a< 0 >(0)) test; // expected-error {{member 'a' used before its declaration}}
----------------
a-tarasyuk wrote:
> I think it generally DOES make sense to try the lookup?
In the case of viable functions, the checker tries to recover even when the candidate list is empty.
https://github.com/llvm/llvm-project/blob/416c3ce0138ff4039dab13ff634ee6392b9a3c7b/clang/lib/Sema/SemaOverload.cpp#L14056-L14059
https://github.com/llvm/llvm-project/blob/416c3ce0138ff4039dab13ff634ee6392b9a3c7b/clang/lib/Sema/SemaOverload.cpp#L13844-L13857
Once the lookup is complete
https://github.com/llvm/llvm-project/blob/df935ff4eca91013553edbf3ca1d45b568f6709f/clang/lib/Sema/SemaExpr.cpp#L2471
It identifies the expression as a dependent member
https://github.com/llvm/llvm-project/blob/df935ff4eca91013553edbf3ca1d45b568f6709f/clang/lib/Sema/SemaExpr.cpp#L2490
This is the entry point for these kinds of names, where we can try to stop the recovery process that causes the crash. Or should we skip building recovery call expression entirely for such cases?
https://github.com/llvm/llvm-project/pull/107786
More information about the cfe-commits
mailing list