[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