=?utf-8?q?André?= Brand <andre.br...@mailbox.org>, =?utf-8?q?André?= Brand <andre.br...@mailbox.org>,thebrandre <andre.br...@mailbox.org>, =?utf-8?q?André?= Brand <andre.br...@mailbox.org> Message-ID: In-Reply-To: <llvm.org/llvm/llvm-project/pull/121...@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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
