[Lldb-commits] [clang] [lldb] [Clang] Introduce OverflowBehaviorType for fine-grained overflow control (PR #148914)

[John McCall via lldb-commits]

rjmccall wrote:

> > I really don't understand why `_BitInt` and `_Complex` are being brought up here.
> 
> I can explain my reasoning. `xxx int` can be read one of two ways: `xxx` is a type qualifier like `const` (e.g., `const int`) or is a type specifier like `_Complex` (e.g., `_Complex float`). If it's a qualifier, I expect lvalue to rvalue conversion to drop the extra qualifying information, but if it's a type specifier, I expect no change for the type on lvalue to rvalue conversion. To me, `__ob_trap` is far closer to a type specifier than it is a type qualifier; we don't want to drop the information on conversion.
> 
> I think it would be confusing for template specializations to notice `__ob_trap` but overloading ignores it. e.g.,
> 
> ```
> template <typename Ty>
> struct S {
>   static constexpr int value = 0;
> };
> 
> template <>
> struct S<int> {
>   static constexpr int value = 1;
> };
> 
> template <>
> struct S<__ob_trap int> { // Ok, not a redefinition
>   static constexpr int value = 2;
> };
> 
> void func(int) {}
> void func(__ob_trap int) {} // error: invalid redefinition
> ```

Oh, it's definitely a type specifier. However, because the intended design is to drop this in while minimizing ABI incompatibility (to which I think should be added: without directly impacting callers), I think there are strong design arguments for applying certain qualifier-like behaviors to it, like ignoring it at the top level of a parameter type when computing the signature of a function.

It is important to distinguish something requiring slightly more effort to specify in a standard, which does not matter, and something being confusing for users, which matters a lot. Your template vs. redeclaration example is exactly what happens with qualifiers, and I do not think it has ever been a problem for users. Actually allowing overloading based on a parameter being `__ob_trap int` vs. `int`, when these types have exactly the same integer rank, would be *extremely* confusing for users if they ever found themselves writing it. It is the sort of language design mistake that leads to style guidelines that actively resist what you were trying to accomplish in the language, like "never declare a parameter `__ob_trap`".

https://github.com/llvm/llvm-project/pull/148914