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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
