================
@@ -7567,9 +7567,13 @@ def warn_arith_conv_mixed_enum_types_cxx20 : Warning<
"%sub{select_arith_conv_kind}0 "
"different enumeration types%diff{ ($ and $)|}1,2 is deprecated">,
InGroup<DeprecatedEnumEnumConversion>;
-def err_conv_mixed_enum_types_cxx26 : Error<
+
+def err_conv_mixed_enum_types: Error <
"invalid %sub{select_arith_conv_kind}0 "
"different enumeration types%diff{ ($ and $)|}1,2">;
+def warn_conv_mixed_enum_types_cxx26 : Warning <
+ err_conv_mixed_enum_types.Summary>,
+ InGroup<EnumEnumConversion>, DefaultError;
----------------
AaronBallman wrote:
I don't disagree (it does add a new enum value), but I am starting to think
this ABI requirement is onerous enough to be worth rethinking the scope of it.
The point to the ABI requirement is that you should be able to use Clang as a
library interchangeably between the dot releases. The platform calling
convention ABI does not change when an enumeration gains a new enumerator, nor
does name mangling behavior change. In fact, adding an enumerator can only
increase the number of valid integer values that can be represented by the
enumeration, which means the addition won't introduce new UB but could remove
UB by widening the range of valid values. So I think this kind of change isn't
introducing a kind of ABI break we need to avoid.
Or am I missing something?
https://github.com/llvm/llvm-project/pull/139396
_______________________________________________
llvm-branch-commits mailing list
llvm-branch-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-branch-commits
