[PATCH] D150226: [Clang] Remove ability to downgrade warning on the diagnostic for setting a non fixed enum to a value outside the range of the enumeration values

Shafik Yaghmour via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu May 18 12:11:54 PDT 2023


shafik added a comment.

In D150226#4353911 <https://reviews.llvm.org/D150226#4353911>, @aaron.ballman wrote:

> In D150226#4353905 <https://reviews.llvm.org/D150226#4353905>, @dim wrote:
>
>> I submitted a similar workaround for the FreeBSD devel/gdb port, via https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271045 that also applies `-Wno-enum-constexpr-conversion`. As the upstream commit message said, they didn't see any other good way to get rid of the warning, so if there is a workaround clang is OK with, that would be nice. Still, I don't really understand what the value is of making this warning into an error, that is not suppressible?
>
> One of the major selling points to `constexpr` functions in C++ is that they cannot contain UB -- if your code compiles, it is correct. This bug that we've fixed was another instance of us accidentally allowing UB in a constant expression context when we shouldn't have. FWIW, I pointed out a reasonable workaround for the freebsd issue: https://reviews.llvm.org/D150226#4342516

Also note, one of the bugs I reference shows how this breaks SFINAE: https://github.com/llvm/llvm-project/issues/57176 and that is not easily fixable. So this is non-conforming since it breaks valid code.

There are two basic work arounds. One give the enum a fixed underlying type:

  enum E : int {}

which will give the whole range of values to work with or if there is a one specific error value they want they can explicitly add an error enumerator and make the error value explicit.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D150226/new/

https://reviews.llvm.org/D150226



More information about the cfe-commits mailing list