carlosgalvezp wrote:
Thanks @shafik , I wasn't aware! I will then close this PR and continue the
discussion on Phab.
https://github.com/llvm/llvm-project/pull/67170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin
https://github.com/carlosgalvezp closed
https://github.com/llvm/llvm-project/pull/67170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
shafik wrote:
This change is a lot more involved, this is on my list of things to do. See the
discussion here: https://reviews.llvm.org/D150226
https://github.com/llvm/llvm-project/pull/67170
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
h
carlosgalvezp wrote:
Not sure what happens with the failed job in CI, I rebased on latest trunk and
ran the entire `ninja check-clang` suite and it passed successfully. Do I need
some special CMake configuration flag to enable the failing test?
About the patch itself - casting outside of range
llvmbot wrote:
@llvm/pr-subscribers-clang
Changes
Casting an int into an enum is undefined behavior if the int is outside of the
range of the enum. UB is not allowed in constant expressions, therefore the
compiler must produce a hard error in that case.
However, until now, the compiler p
https://github.com/carlosgalvezp created
https://github.com/llvm/llvm-project/pull/67170
Casting an int into an enum is undefined behavior if the int is outside of the
range of the enum. UB is not allowed in constant expressions, therefore the
compiler must produce a hard error in that case.