rjmccall wrote: > > I understand that this doesn't _have_ to be seen as different. I am telling > > you that is practically useful to _make_ it different in order to enable > > incremental adoption of `__ob_trap`, because otherwise you cannot add > > `__ob_trap` to a parameter in order to force uses of it to be checked > > within the function without having to deal with potential breakage in every > > caller of the function. > > I agree that this helps with adoption and as such I am OK with that approach. > Later on, we can get the behavior with some strong typedef thing. > > The other stuff regarding overloading and templates should match probably > `_Atomic`, `_Complex` and `_BitInt` as Aaron described.
I really don't understand why `_BitInt` and `_Complex` are being brought up here. `_Complex float` and `float` are totally different types with different information content and representations. `_BitInt`... I can't even figure out what the analogy with `_BitInt` is supposed to be; I guess you're thinking specifically of `_BitInt(32)` vs. `int`, which do have the same information content, but there's no guarantee in the standard that they have the same representation, and the standard obviously has to have rules that apply to `_BitInt` in general and is not likely to make special rules for `_BitInt`s that happen to have the same width as a standard integer type. In contrast, `__ob_trap T` will have the exact same information content and representation as `T`, and clients like the kernel will absolutely be expecting that changing some struct member or parameter from one to the other will not be ABI-breaking. The overloading behavior of `_Atomic` is just a silly oversight, not some deeply-thought-out feature that we should be treating as meaningful precedent. https://github.com/llvm/llvm-project/pull/148914 _______________________________________________ lldb-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
