ABI compatibility: remove section on target features

[RalfJung]

Once #127731 lands, we will properly diagnose ABI issues caused by target feature mismatch (at least on tier 1 targets). So I'd say we can remove the corresponding part of the docs here -- this is now something the compiler can take care of, so programmers don't need to be concerned. For now this is just a lint, but that's just a transition period, like in prior cases where we fix I-unsound bugs by adding a new check that goes through the "future incompatibility" stages. We have decided that it's actually a bug that we have ABI risks around target features, and we shouldn't document that bug as-if it was intended behavior.

Cc @rust-lang/opsem @chorman0773 @veluca93

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[Mark-Simulacrum]

I guess this is now waiting on #132173 due to the revert?

I'm wondering if we should keep this section, while noting that the requirements are typically guaranteed by the compiler. It's confusing to me to say this is just guaranteed by the compiler -- maybe I'm missing something, but we probably can't do that across e.g. language boundary / translation unit, where I manually write (or use bindgen, etc.) extern { ... } blocks to reference foreign functions? Do we have some other docs that specify how "closely" I need to match that foreign function's definition? Seems like these would be the docs I need to read...

[Mark-Simulacrum]

The way it is fixed is by making it a hard error to call or declare an extern "C" function that passes a SIMD type by-value without enabling the target feature that enables SIMD vectors of the appropriate size. The reason it is made a hard error is that these functions end up having a different ABI depending on whether that target feature is enabled or not.

At least if this is the fix, it seems like while Rust may require you to enable the feature, it's not clear from that that GCC or Clang have similar enforcement, so I can still run into trouble?

[RalfJung]

This section of the docs is only about Rust-to-Rust calls. Calls to other languages would need to list which Rust types are compatible with which C types.

[RalfJung]

But yeah this is blocked on re-landing the reverted PR.

[Mark-Simulacrum]

Ah, right. I remember that discussion when we added this :) In that case, r=me once dependency lands.

I do think it would be good to add an explicit note about FFI somewhere -- the page doesn't seem to mention that at all today in the actual text, only by omission -- and omission feels somewhat unfortunate :)

[RalfJung]

Well it talks about which Rust types are compatible with which Rust types. So it seems fairly clear that this cannot talk about C to/from Rust calls? I don't know what is the right place to document FFI guarantees, but certainly not the stdlib. Probably the reference should have an FFI section.

[Mark-Simulacrum]

Well it talks about which Rust types are compatible with which Rust types. So it seems fairly clear that this cannot talk about C to/from Rust calls?

I'm not sure I agree. Without an explicit note, and with types like std::ffi::c_int being documented as "Equivalent to C’s signed int (int) type.", it seems plausible (expected!) for a user to interpret that as meaning a int typed argument on the C side is the same as c_int in Rust for an extern "C" function.

If we want to avoid such an assumption, I think adding "These guarantees/requirements only apply to Rust <> Rust calls. The requirements for cross language calls are not currently documented here." could help.

In any case, I think that's a separate topic -- let me file a PR proposing such language and we can discuss there.

[RalfJung]

@Mark-Simulacrum so modulo waiting for #132173, is this good to go?