=?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]>, =?utf-8?q?Félix?= Cloutier <[email protected]> Message-ID: In-Reply-To: <llvm.org/llvm/llvm-project/pull/[email protected]>
workingjubilee wrote: I apologize if you have considered this already, there was a lot of context to catch up on and I only became aware of this proposal... now? Rust implements transforms that operate on `bool` and rely on it being only 0x00 or 0x01 even while at `-Copt-level=0`... `-O0`, if you prefer. And Rust tooling that binds against C usually assumes that it can just... treat a bool as a bool, yanno? Indeed, we have *long* intended to have our `bool` interoperate with the C `_Bool` where possible. If there are platforms which differ in this regard, we have not had a request to support them that I am aware of, and as long as there are two bitpatterns and only two, I feel confident we could work something out. The transforms are so-called "niche optimizations" that make certain ADTs like `Option<bool>` occupy only 1 byte. This relies on the property that at least some bits must be functionally irrelevant to reading a byte that has only two values as a bool, i.e. that `-fstrict-bool=nonzero` is a *strictly invalid* interpretation. That's a very easy to observe part of Rust's implemented language semantics, and depending on how you read certain prior RFCs and decisions it may simply be a guaranteed feature already. If clang surrenders this UB to user control, people may set `-fno-strict-bool` routinely and invite dialectic drift to set in, just like it did with `-fno-strict-aliasing`. However, unlike `-fstrict-aliasing`, this is not simply an internal feature of the language semantics, invisible outside the language: rather, C code passing a `bool` arg may start to expect to get away with passing `0x02` or something, just like C code from certain programming cultures habitually operates as if `-fno-strict-aliasing` is on, because in their experience it always is. Yet Rust will struggle to do anything with this but treat it as UB, even though we can otherwise mechanically interoperate with correctly-written C code. Accordingly, I view this as less a mere optimization flag and more a redefinition of a fundamental type, more akin to `-funsigned-char`. *That's* probably going to be a right pain to interoperate with, but at least that only affects a type alias! Rust has been able to pervasively rely on such strictness because it has been the practical, observed behavior of C and C++ programs for a long time, and conformant to our readings of the C standard. This is true even though we **do not** rely on the supposedly "parallel" flag of `-fstrict-enums` cited in the original RFC, as conversely, C enums are clearly defined as being just a set of funny-looking constants by the standard. We have even started to weigh deprecating our "represent this as its C equivalent" for numeric-variant-only enums, because they're rarely what anyone wants. ...I mean, I suppose I have you all at a disadvantage, because Rust kinda does have ways to interact with "a value that ought to be in this set of bitpatterns for the type, but actually could be anything, even uninitialized". Yet that isn't something Rust user code can do for random types that are passed by value, as the same thing happens: it's already "gone", and the "typed copy" operation has happened, and the abstract machine is now in an invalid state. So unless we get a very clever idea, I personally expect more likely events are that we either reject this as a possibility, or simply try to pessimize our codegen at the boundaries we know we are hitting C interop for the sake of damage control. We aren't the C compiler so we can't really know what flags any calling C was compiled with, and "Rust decides to accept `bool` having 3+ valid bitpatterns" seems about as likely to me as "Her Majesty Queen Elizabeth II gives a speech on compiler design tomorrow". But I will not be the final word on that, to be clear, so maybe I'm about to hear a very interesting news report. https://github.com/llvm/llvm-project/pull/160790 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
