3 ms·

Rust must stabilize its ABI if it seeks to be a useful systems language. You usually don't have to worry about ABI for LLVM and GCC interaction, so why should y

Rust must stabilize its ABI if it seeks to be a useful systems language. You usually don't have to worry about ABI for LLVM and GCC interaction, so why should you need to worry about rustc and gccrs interaction? C++ STL and MSVC are known exceptions. In other words, anything produced by gccrs will already be incompatible with rustc. Yeah that was me I'm afraid. That said, I strongly disagree that -fno-strict-aliasing changes language semantics in an appreciable way, since using it to deliberately circumvent the aliasing rules still wouldn't be sanctioned by Rust. You'd just have a predictable, mostly acceptable form of "UB" rather than whatever glitter the compiler feels like farting into your face. If I was asking for a flag that broke existing code, I'd understand, but since this change is totally backwards compatible, I don't understand the objection.

steveklabnik 5y ago
ABI is a complete red herring. The issue is about taking source code that you've written in your almost-Rust and compiling it with Rustc, leading to miscompilations. EDIT, responding to yours: it was explained in the thread, at length: https://internals.rust-lang.org/t/add-rustc-flag-to-disable-mutable-no-aliasing-optimizations/14404 https://internals.rust-lang.org/t/add-rustc-flag-to-disable-... it's not backwards compatible. The very first post is the language team co-lead explaining: > Whether or not rustc makes use of the codegen backend's support for optimizing &mut using noalias, by specification and defition &mut is still an exclusive reference. Various parts of the language and library depend on that exclusivity for soundness. &mut is not the mechanism you're looking for.
- Subsentient 5y ago
  Again, UB is UB, and if the author of said program wrote it to rely on -fno-strict-aliasing in gccrs, that's probably bad code. It doesn't mean, however, that -fno-strict-aliasing isn't useful. The truth of the matter is that I'm horrified by stacked borrows and what it represents, because it will make unsafe code extremely painful to write and extremely brittle. Rust needs a way to opt-out of these aggressive optimizations, like every other systems language ever has had for the majority of their lifespans. A function attribute would be acceptable, but the truth is, Rust is not open to any such enhancements for unsafe code. They seem hell-bent on enforcing "safety" on deliberately unsafe code, even if it breaks that code in subtle ways. EDIT: I have no interest in arguing further. This is a hopeless and frankly rather disheartening topic for me. Rust has brought out more strong emotions from me than any other language I have ever used. I suppose why it matters to me is because I see such potential in Rust, and I feel it's being taken down the wrong path. But, that's just my opinion.
  - steveklabnik 5y ago
    > Rust needs a way to opt-out of these aggressive optimizations As the next sentence of that very first post said: > There is a way to tell the language exactly what you want: you can use unsafe, raw pointers, UnsafeCell, and abstractions built atop them. And again, this is not about optimization, this is about semantics. What you want is a different semantics, which is why it is not something that we would accept as a flag. Rustc does already let you change what optimizations are done to your code (trivially: -C opt-level=n). That is not an issue. This just isn't about optimization.
    - Subsentient 5y ago
      Yes, it is about optimization. By your own admission, rustc allows you to set -C opt-level, and that would probably change semantics to the desired, but at significantly worse performance. You don't seem to understand the concept of undefined behavior. What I'm trying to say is that even if rustc generates the correct output, the code could still officially be declared UB, just as it is now in debug mode. If it breaks logic that relies on the exclusivity of &mut, well, that's what UB does, it breaks things. It is entirely an optimization option. You're right that I think it would be nice if you could have multiple &muts created from raw pointers, but I'm not asking for that. The reason these things are issues at all is because Rust uses these references for things like RAII (e.g. &mut self in drop()), and there's no way to use raw pointers instead. If Rust provided a way to use raw pointers more easily in the places you need them, this would be a non-issue. But right now, the unsafe/safe boundary is very dangerous in Rust, so dangerous that I'm uncomfortable working in it even though I've worked in C and C++ for over a decade, and it's entirely a self-inflicted wound by the Rust devs.
      - steveklabnik 5y ago
        > You don't seem to understand the concept of undefined behavior Okay, now I am done here, like you said you were before this post.
        Subsentient 5y ago
myrrlyn 5y ago
> Rust must stabilize its ABI if it seeks to be a useful systems language. ? no it mustn't. what's the c++ abi

steveklabnik 5y ago

ABI is a complete red herring. The issue is about taking source code that you've written in your almost-Rust and compiling it with Rustc, leading to miscompilations. EDIT, responding to yours: it was explained in the thread, at length: https://internals.rust-lang.org/t/add-rustc-flag-to-disable-mutable-no-aliasing-optimizations/14404 https://internals.rust-lang.org/t/add-rustc-flag-to-disable-... it's not backwards compatible. The very first post is the language team co-lead explaining: > Whether or not rustc makes use of the codegen backend's support for optimizing &mut using noalias, by specification and defition &mut is still an exclusive reference. Various parts of the language and library depend on that exclusivity for soundness. &mut is not the mechanism you're looking for.

Subsentient 5y ago
Again, UB is UB, and if the author of said program wrote it to rely on -fno-strict-aliasing in gccrs, that's probably bad code. It doesn't mean, however, that -fno-strict-aliasing isn't useful. The truth of the matter is that I'm horrified by stacked borrows and what it represents, because it will make unsafe code extremely painful to write and extremely brittle. Rust needs a way to opt-out of these aggressive optimizations, like every other systems language ever has had for the majority of their lifespans. A function attribute would be acceptable, but the truth is, Rust is not open to any such enhancements for unsafe code. They seem hell-bent on enforcing "safety" on deliberately unsafe code, even if it breaks that code in subtle ways. EDIT: I have no interest in arguing further. This is a hopeless and frankly rather disheartening topic for me. Rust has brought out more strong emotions from me than any other language I have ever used. I suppose why it matters to me is because I see such potential in Rust, and I feel it's being taken down the wrong path. But, that's just my opinion.
- steveklabnik 5y ago
  > Rust needs a way to opt-out of these aggressive optimizations As the next sentence of that very first post said: > There is a way to tell the language exactly what you want: you can use unsafe, raw pointers, UnsafeCell, and abstractions built atop them. And again, this is not about optimization, this is about semantics. What you want is a different semantics, which is why it is not something that we would accept as a flag. Rustc does already let you change what optimizations are done to your code (trivially: -C opt-level=n). That is not an issue. This just isn't about optimization.
  - Subsentient 5y ago
    Yes, it is about optimization. By your own admission, rustc allows you to set -C opt-level, and that would probably change semantics to the desired, but at significantly worse performance. You don't seem to understand the concept of undefined behavior. What I'm trying to say is that even if rustc generates the correct output, the code could still officially be declared UB, just as it is now in debug mode. If it breaks logic that relies on the exclusivity of &mut, well, that's what UB does, it breaks things. It is entirely an optimization option. You're right that I think it would be nice if you could have multiple &muts created from raw pointers, but I'm not asking for that. The reason these things are issues at all is because Rust uses these references for things like RAII (e.g. &mut self in drop()), and there's no way to use raw pointers instead. If Rust provided a way to use raw pointers more easily in the places you need them, this would be a non-issue. But right now, the unsafe/safe boundary is very dangerous in Rust, so dangerous that I'm uncomfortable working in it even though I've worked in C and C++ for over a decade, and it's entirely a self-inflicted wound by the Rust devs.
    - steveklabnik 5y ago
      > You don't seem to understand the concept of undefined behavior Okay, now I am done here, like you said you were before this post.
      - Subsentient 5y ago

myrrlyn 5y ago

> Rust must stabilize its ABI if it seeks to be a useful systems language. ? no it mustn't. what's the c++ abi