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

[Justin Stitt via lldb-commits]

JustinStitt wrote:

Pinging @kees as he might have concerns with the first 80% of your comment but for me this part was interesting:

@rjmccall
> There was a secondary discussion about whether OBTs should be part of the signature of the function for the purposes of overloading, mangling, and so on, and I think the consensus there was "definitely not". Again, you want adopting `__ob_trap` on a parameter to not be an ABI-breaking change.

I think a goal of OBT's is that they are their own type and should overload and mangle like `_BitInt` or `_Atomic` does. OBTs aren't just comments or sugar, they represent real semantic differences when they are present versus when they are not. An `__ob_wrap int` and an `int` should not be treated the same because they are not the same, similar to `num::Wrapping` in rust.

Back to `_Atomic` and `_BitInt`, `_Atomic` things cannot be used as the sole discriminating factor during overload set formation, see:

```c
void foo(_Atomic int b) {}
void foo(int b) {}

void ambiguous     (int b) { foo(b); }
void also_ambiguous(_Atomic int b) { foo(b); }
```

Meanwhile, `_BitInt` can be used to discriminate overloads:

```c
void foo(_BitInt(12) b) {}
void foo(int b) {}

void picks_exact_match(_BitInt(12) b) { foo(b); }
void also_picks_exact_match(int b) { foo(b); }

void ambiguous_no_exact_match(_BitInt(13) b) { foo(b); }
void ambiguous_same_conversion_ranks_for_both(long b) { foo(b); }
```

... And both _are_ still mangled. So this suggests to me we can go a similar route with OBTs, mangle (and break ABI) but don't allow overloading with them. Thoughts on this?

I'm no expert on what sorts of types should constitute ABI changes introduced by different mangled signatures but OBTs feel like they carry enough semantic weight to break ABI, I think this is what user's would expect as well. I am happy to learn more about this so please correct me if I am wrong.

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