Deprecate core::arch::{x86,x86_64}::__{read,write}eflags

[gnzlbg]

Compiler-generated code can use the eflags register in between __{read,write}eflags calls, making these two intrinsics impossible to use correctly for the cases in which the user reads-modifies-writes to the eflags registers.

Even read only operations like performing an alu operation in Rust, and then checking sf or zf by calling these intrinsics are not guaranteed to work either.

The only reliable way to perform these operations is using a single assembly block (e.g. via inline assembly).

This is further discussed in rust-lang/stdarch#485

This issue proposes to deprecate these intrinsics and mark them with #[doc(hidden)], so that we can potentially remove them, maybe in the Rust 2018 edition.

EDIT: There is a PR implementing the deprecation here that would need review before being merged: rust-lang/stdarch#494

cc @BurntSushi

[gnzlbg]

cc @rkruppe @stevecheckoway - also related to #51691

[BurntSushi]

cc @rust-lang/libs

[BurntSushi]

The motivation and deprecation seem fine to me. I don't know the procedural details and exactly what we're allowed to do though.

[SimonSapin]

I have no opinion on these functions. The process is that we cannot remove stable APIs once they reach the stable channel, which those did 5 days ago. Editions do not help here since only one std is shipped with a given compiler, for all editions. (String for example needs to be the same type for all crates in the same program, even if those crates are in different editions.)

We can add #[rustc_deprecated(since = "1.29.0", reason = "something")] (which causes usage to emit a warning) and #[doc(hidden)].

[est31]

Editions do not help here since only one std is shipped with a given compiler, for all editions. (String for example needs to be the same type for all crates in the same program, even if those crates are in different editions.)

What we can technically do is to change resolution to ignore functions/structs/etc that are present in the metadata of some given crate if those functions wish to not be present on that edition. That wish being expressed by some language feature like idk strawman syntax #[only_on_edition("2015")]. That wouldn't mess with the type system.

A slightly more relaxed approach is to add a lint or a hard error that points out that while the function exists, you are not allowed to use it any more. A warn by default lint wouldn't be much of an advantage over the status quo, use of deprecated functions already now emits a lint :p.

I think that having edition specific functions is a bad idea for a different reason: it would preclude automated edition updates of codebases, at least as long as those codebases are using one of those functions that are not available in the new edition.

[est31]

To add to that: such automated updates are one of the features that editions guarantee. I guess you have a trade off now between the ability to do automated updates flawlessly and the ability to remove deprecated APIs.

[hanna-kruppe]

I really don't see any point in forbidding usage of some path in only some editions (not only for this case, but in general). Being hidden + warning on use is sufficient to make most people migrate away from it, and those who aren't deterred by it will likely just work around removal in an edition anyway. It also doesn't allow us to remove the code supporting the feature.

[sfackler]

Deprecation seems fine and sufficient to me.

[gnzlbg]

So if the libs team signs on the deprecation + #[doc(hidden)], can some of you review the PR in the stdsimd repo that implements that? rust-lang/stdarch#494

I've basically just used rustc_deprecated instead of deprecated, but I've never done that before and don't know if there is anything else to take care of while bootstraping.

[Mark-Simulacrum]

This is waiting on an update to stdsimd.

[est31]

@Mark-Simulacrum no, my PR #51695 updated stdsimd to a suiting version. You only need to close this issue now.

[Mark-Simulacrum]

Hm, I guess my grep failed then. Thanks!