[clang] Regression: Tag lookup implementation edge case doesn't produce necessary diagnostic

[fnriv]

Consider the following test for the C++ 20 standard:

// Copyright © 2025, Solid Sands B.V.

enum animals { penguin, lion, tiger };
namespace zoo {
    namespace animals {
        int lion = 1;
    }
}

int main() {
   animals a;

   using namespace zoo;
   using enum animals; /* Diagnostic expected */

   a = lion;

   return a == lion; 

} 

When running the below command, there should be an error diagnostic regarding the ambiguous reference to animals that is no longer produced in the current HEAD of main:

Command: clang -std=c++20 {path_to_test}

Expected output:

clang/test/sandbox/enum_ambiguous_test.C:14:15: error: reference to 'animals' is ambiguous
   14 |    using enum animals; /* Diagnostic expected */
      |               ^
clang/test/sandbox/enum_ambiguous_test.C:3:6: note: candidate found by name lookup is 'animals'
    3 | enum animals { penguin, lion, tiger };
      |      ^
clang/test/sandbox/enum_ambiguous_test.C:5:15: note: candidate found by name lookup is 'zoo::animals'
    5 |     namespace animals {
      |               ^
1 error generated.

I found this issue found by running SuperTest by Solid Sands. I ran a git bisect to find the commit that caused the diagnostic to disappear, which identified PR #112166. The PR acknowledges that there may be some edge cases to the tag lookup, and I believe this is one of them.

[shafik]

Note, we can't use source code from other project unless their licence is compatible (I may not be using correct language here) with the use under llvm licence. So before submitting code via bugs and or PRs please verify the code is usable or provide code that is produced independently.

CC @AaronBallman

[fnriv]

Hi @shafik,

I created this example test myself- it is an equivalent minimum reproducer test of a separate Solid Sands test used to identify the regression. I received approval from Solid Sands to post this code as long as I added the copyright and mentioned that I used their internal SuperTest beforehand.

Thank you for the note, hope this clarifies things!

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Faith Rivera (fnriv)

Consider the following test for the C++ 20 standard:

// Copyright © 2025, Solid Sands B.V.

enum animals { penguin, lion, tiger };
namespace zoo {
    namespace animals {
        int lion = 1;
    }
}

int main() {
   animals a;

   using namespace zoo;
   using enum animals; /* Diagnostic expected */

   a = lion;

   return a == lion; 

} 

When running the below command, there should be an error diagnostic regarding the ambiguous reference to animals that is no longer produced in the current HEAD of main:

Command: clang -std=c++20 {path_to_test}

Expected output:

clang/test/sandbox/enum_ambiguous_test.C:14:15: error: reference to 'animals' is ambiguous
   14 |    using enum animals; /* Diagnostic expected */
      |               ^
clang/test/sandbox/enum_ambiguous_test.C:3:6: note: candidate found by name lookup is 'animals'
    3 | enum animals { penguin, lion, tiger };
      |      ^
clang/test/sandbox/enum_ambiguous_test.C:5:15: note: candidate found by name lookup is 'zoo::animals'
    5 |     namespace animals {
      |               ^
1 error generated.

I found this issue found by running SuperTest by Solid Sands. I ran a git bisect to find the commit that caused the diagnostic to disappear, which identified PR #112166. The PR acknowledges that there may be some edge cases to the tag lookup, and I believe this is one of them.

[zygoloid]

The language rule here was changed by CWG issue 2877, which was adopted as a DR, and Clang implements the new rule. Looks like this test suite is out of date.

[AaronBallman]

Correct, that was implemented in Clang 19.x, so closing the issue. If you think this was done in error, feel free to reopen with more details.

[MarcelAtSolidSands]

Hi @zygoloid,

I'm OK with closing the issue, however, want to comment on "Looks like this test suite is out of date."

You wrote: “The language rule here was changed by CWG issue 2877, which was adopted as a DR, and Clang implements the new rule”.

This test is for written the C++20 standard, and is reported to be compiled with the option “-std=c++20”. CWG issue 2877 is from a (much) later date. If I understand you correctly, clang applies DRs also to older versions of the language standard and therefore potentially changes the behavior of programs compiled with options such as “-std=c++20”.

Instead, our test suites are based on the published version of the standard (C++11/14/20/…) and that is it. This is in line with the opening paragraph of https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html, which states: “Issues with DR […] status are NOT part of the International Standard for C++. […] They should not be considered definitive until or unless they appear in an approved Technical Corrigendum or revised International Standard for C++.”

That is also the policy of the safety-critical and mission-critical industries that we are active in. Applications are approved against defined standards, and those standards do not change based on later findings.

[AaronBallman]

If I understand you correctly, clang applies DRs also to older versions of the language standard and therefore potentially changes the behavior of programs compiled with options such as “-std=c++20”.

Correct. In C++, Defect Reports are (generally speaking) bugs in the language. When an issue is adopted by the committee as a defect report, the expectation is that the fix will be applied in all language modes where the bug is present, so it does change previous versions of the standard. However, there's no conformance requirement that this happen; strictly speaking the changes are only required in the language standard in which the fix was released.

C has a slightly different approach in that C's defect reports are most often "you've read the standard wrong (perhaps because we put the wrong words in it), you should read it this way instead" generally speaking. The end effect is the same as with C++ though; the feature was always expected to be implemented a particular way and the new understanding may change that implementation in older language modes. Only recently has WG14 started keeping an explicit list of papers that were adopted with encouragement for implementers to apply the changes in earlier standards modes: https://www.open-std.org/jtc1/sc22/wg14/www/previous.html

The way Clang handles this is: we default to fixing the DR in all language modes, but if that's disruptive for some reason we may decide to only fix forward, or to add ABI tags so you can get either the old or the new behavior, etc.