pirama added inline comments.
================
Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8618-8619
+ "operand argument to %select{overflow builtin|checked integer operation}0 "
+ "must be an integer type %select{|other than plain 'char', 'bool',
bit-precise, "
+ "or an enumeration }1 invalid">;
def err_overflow_builtin_must_be_ptr_int : Error<
----------------
The warning selector is slightly different from the one for the result.
================
Comment at: clang/lib/Headers/stdckdint.h:12
+#define __STDCKDINT_H
+
+/* C23 7.20.1 Defines several macros for performing checked integer
arithmetic*/
----------------
aaron.ballman wrote:
> Should a hosted build attempt to do an include_next into the system library
> and then fall back to the compiler builtins, or should we treat this like
> stdbool.h where the compiler always wins? CC @jyknight @jrtc27 @efriedma
>
> My intuition is that we want to include_next in case the system has better
> facilities than the compiler does.
The `include_next` question is still open. Any preference here?
IMO, since the standard explicitly delegates to the compiler builtin when
available, we may not need to `include_next` - unless there are other
conventions around this.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D157331/new/
https://reviews.llvm.org/D157331
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
