[clang] [clang] Fix implicit integer conversion for opaque enums declared in class templates (PR #121039)

[via cfe-commits]

=?utf-8?q?André?= Brand <andre.brand at mailbox.org>,
=?utf-8?q?André?= Brand <andre.brand at mailbox.org>,thebrandre
 <andre.brand at mailbox.org>,
=?utf-8?q?André?= Brand <andre.brand at mailbox.org>
Message-ID:
In-Reply-To: <llvm.org/llvm/llvm-project/pull/121039 at github.com>


thebrandre wrote:

> The issue number here seems wrong, can you update the description? [#121039 (comment)](https://github.com/llvm/llvm-project/pull/121039#issue-2757453924) (#116525 is a completely unrelated issue)

Thanks for pointing that out @cor3ntin. I messed that up in my last edit.

> That being said, it is missing a changelog entry in clang/docs/ReleaseNotes.rst, can you add one?

Sure. You won't notice it but I literally spent half an hour thinking about this sentence. It's so difficult to be clear, technically correct, and concise at the same time.

> We usually try to diagnose issues as soon as possible, so i still believe there are improvements to be made here. 

I am still undecided here. As far as I understand the standard, this is valid code as long as the enum is not used. It says *The implicit instantiation of a class template specialization causes [...] the implicit instantiation of the definitions of unscoped member enumerations* [[temp.inst]](https://eel.is/c++draft/temp.inst). This feature extensively used for member functions. For example std::vector::resize is not valid for types that are not default-constructible but you can still use std::vector as long as you don't use the bad member functions. 
See here on Compiler Explorer [https://godbolt.org/z/Mn3Y1Ka14](https://godbolt.org/z/Mn3Y1Ka14).

Admittedly, I can't think of any sane use case for this feature on unscoped member enumerations ... but there are very creative people out there. 😉


https://github.com/llvm/llvm-project/pull/121039