AaronBallman wrote: > > IMO, we are better served by a warning diagnostic if we detect these are > > misused. `ParseCXXCondition` (or the C equivalent, but since you are > > returning bool it seems you're not concerned about C?) might be a good > > place to set a variable to enable the warning. > > This is a very good suggestion, thank you very much for it - it might well be > where we end up. My worry is that ignoring warning and diagnostics is rather > common.
You could default the warning to an error to make it more visible to the user. Not certain if that's a bad idea or not though. > If I may be so bold as to inquire: would you and @AaronBallman be slightly > less horrified if the return type variance would be replaced with returning > an odd type that only knows how to `bool`ify itself in conditions? More > explicitly, if instead of `void __builtin_amdgcn_processor_is(const char*)` > what we see is `__amdgpu_predicate_t __builtin_amdgcn_processor_is(const > char*)`, would that be somewhat less bad? There is precedent for special-ish > builtins returning special-ish target types (please consider > `__amdgpu_buffer_rsrc_t` for `__builtin_amdgcn_make_buffer_rsrc` or > `svcount_t`) That would be just as weird, IMO. Having something that's contextually converted to bool but only in some contexts, is going to be confusing in practice. https://github.com/llvm/llvm-project/pull/134016 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
