workingjubilee commented 1 year ago

Proposal

Semi-recently, various targets, in the past, present, and possible future, have raised serious questions, like

"Can Rust even support this target with the language's currently specified semantics?"
"If we do add support this target, will the existing Rust ecosystem actually work with it?"
"Is this target actually stable enough to assert it has stable platform support?"
"How could a crate author indicate they do support this target, despite it being uncommon, and how could users try out crates that don't indicate they support this?"

This suggests there is a troubling coupling between "target support", and "this is definitely a stable target you can rely on having unchanged semantics", and "if rustc supports this target, all crates are expected to, too", in terms of developer experience. This is a problem, as it can hinder even asking questions in depth and at scale about whether target support could work.

We could use a method like #![no_std] to allow crate authors to express they do support an "unusual target". However, for many targets, a crate author may not even know if they don't support that target, thanks to the relatively good cross-platform support in Rust. Even with crates that could otherwise work fine as #![no_std], they are liable to link enough of std, even without trying, to prevent usage. And generalizing such a mechanism for "unusual targets" would put unnecessary pressure on crate authors to opt-in. In order to relieve pressure on possible author expectations to express explicit buy-in, and relieve pressure on target maintainers who might not actually be able to afford committing to community expectations regarding stability of current targets, we can add a compiler flag for experimental usage of support for a target on rustc nightly: -Zexperimental-target.

This will serve as a nightly feature gate, where some targets may have their support gated on this. Many tier 3 targets already have their support de facto relegated to nightly usage with something like -Zbuild-std, but in the event -Zbuild-std gets stabilized, this flag would effectively preserve such a gate for certain targets. It might also allow adding tier 2 support for a target but still requiring -Zexperimental-target, so that Rust programmers may benefit from a precompiled libstd.

No current targets are proposed for gating on this flag, but it is suggested that maintainers that add targets they know are experimental in terms of Rust support (as opposed to merely inadequately supported by the Rust compiler and standard library) opt in to this. Preferably be with a description of why, so that we may know when it might be made non-experimental, but the social messaging of opting in to such a flag is self-justifying.

To wit: this isn't about your {x86_64,aarch64}-yet-another-unix, nor even your niche_risc-bare-metal, but about your proverbial exotic_arch-experimental_kernel.

Likewise, no new means for indicating "this crate supports unusual targets" are yet proposed, as that is a matter for T-(lang|libs)? consideration. The idea would be to allow people to discuss such mechanisms without simultaneously proposing shutting such targets out of the entire Rust ecosystem, by eventually using -Zexperimental-target, or similar, to experiment with crates that don't opt-in, without forking each one, which is impractical when testing a deep dependency tree like tokio. It might also allow crate authors to use different strategies than "demand each platform add their support to your crate".

Mentors or Reviewers

...Do I have a volunteer?

Process

The main points of the Major Change Process are as follows:

[x] File an issue describing the proposal.
[ ] A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
- Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
- Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
[ ] Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

rustbot commented 1 year ago

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors