Renaming targets might be a breaking change

[imsnif]

Hi all,

I am unsure if this is the right place for this sort of issue and apologize if it isn't. I would also like to stress that I fully understand this issue is not currently actionable, but I want to bring it to the attention of the maintainers in case this is a blind spot. If this has been discussed to death elsewhere (that I could not find) I also apologize for the extra noise.

Recently, through compiler warnings I have been made aware of: https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html#renaming-wasm32-wasi-to-wasm32-wasip1

Namely, renaming the wasm32-wasi target to wasm32-wasip1. In Zellij, we bundle minor applications that we call plugins - compiled to this target - within our executable. This is how we compile and distribute our software and represents a compromise of various factors. Renaming this target represents a breaking change for us. It means we will no longer be able to compile the same project for the newer rust version, and that if we upgrade our toolchain, we will no longer be able to compile the same project for a (much) older version.

This is not a big deal for us. Making the change should be a trivial search/replace, and we don't absolutely have to support much older toolchains. However, as a user of the language I assumed (perhaps mistakenly) that targets are an external user-facing API. That any non-backwards-compatible changes to them would be considered breaking changes and should only be expected in major version bumps. Since this was not the case here, it gets me a little worried that perhaps either I do not understand the breaking changes policy (even after reading the relevant RFC) or there is some sort of miscommunication going on between the language developers and at least some of its users. Or - of course - this is a blind spot.

In case this is the latter, I wanted to bring it to the attention of the maintainers. Not for this change of course - as I understand it's already very much underway - but at least for future changes.

Thanks for all the work everyone is doing.

[jieyouxu]

This is intentionally a breaking change and why there's a migration timeline https://blog.rust-lang.org/2024/04/09/updates-to-rusts-wasi-targets.html#timeline to help people migrate off the old target name. This included a period of warning if people were still using wasm32-wasi in 1.79-1.81 on stable.

cc @alexcrichton for the wasm targets.

cc @wesleywiser and @davidtwco: do we have any specific target renaming/deprecation/removal policy? FWIW wasm32-wasi/wasm32-waspi1 are Tier 2 targets. The change did go through:

1. Rename wasm32-wasi target to wasm32-wasi-preview1 compiler-team#607: MCP for initial target rename proposal
2. Smooth the renaming transition of wasm32-wasi compiler-team#695: MCP for smoothing transition of the rename

cc tracking issue #113364

[imsnif]

For what it's worth, I was going by this when investigating the Rustlang policy: https://rust-lang.github.io/rfcs/1105-api-evolution.html#major-change-renamingmovingremoving-any-public-items

[jieyouxu]

That policy governs stability guarantees w.r.t. language features, not compiler target support. Please refer to Target Tier Policy w.r.t. to compiler target support. In particular, the relevant part is

A tier 2 target may be demoted or removed if it no longer meets these requirements. Any proposal for demotion or removal will be CCed to the target maintainers, and will be communicated widely to the Rust community before being dropped from a stable release. (The amount of time between such communication and the next stable release may depend on the nature and severity of the failed requirement, the timing of its discovery, whether the target has been part of a stable release yet, and whether the demotion or removal can be a planned and scheduled action.)

[imsnif]

Fair enough. Thanks for the link. As a user of the language who is not aware of its internals - I'm not sure I could have easily found this document on my own, or indeed understood that this is what I'm looking for. I looked for "Rustlang breaking changes" and found the above RFC. Maybe I'm the problem - maybe this is clear to everyone else except me.

But from my perspective - without knowing the internals of the tool I'm using - I look at the semver version to understand if I should expect breaking changes or not. And I expect public APIs (including in my view compilation targets, CLI flags, etc.) to not change in a way that would break old code.

This distinction is now clearer to me, thanks for pointing it out. I only wonder what other blind spots I have regarding breaking changes that are not covered in the breaking changes RFC. I am not a Rustlang language developer, simply a user of the language. Do with this feedback as you wish. :)

[jieyouxu]

FWIW I think compiler team did want to clarify/amend the Target Tier policies a bit, since it can be a bit confusing.

[alexcrichton]

@imsnif you might be interested in the target tier policy where the wasm32-wasi target (and wasm32-wasip1) are classified as tier 2 right now.

[imsnif]

Thanks for pointing this out @alexcrichton !

Here was my process and reasoning:

1. I look at Rust's version, see that it's above 1.0.0 and so assume breaking changes only happen in major version changes
2. Seeing this warning, I get confused. I realize I probably view a "breaking change" in a different way than the language developers, and so search for "rust breaking changes", I find this: https://rust-lang.github.io/rfcs/1105-api-evolution.html
3. As a simple user of the language and not a developer of the language itself, I am not aware of distinctions between the Rust standard library, the targets, tiers or any such. My confusion deepens and I open this issue. I am then pointed to the above document, which explains this specific distinction.

Right now, I understand why this change (which I view as breaking) will happen in a non-major version. I am however left with a concern about other potential breaking changes which do not fit into this mold (either the standard library or the target tier system). Things I do not even know to ask about because I don't have the relevant domain knowledge (eg. like here - what's the difference between breaking changes in the standard library and in specific compilation targets based on a tier system).

I look at semver as a way for the language developers to communicate (breaking) changes to me. As the target of this communication and a person who relies on this software heavily, I am currently left quite confused - mostly about the future and the unknown unknowns that I have regarding what constitutes a breaking change and what doesn't.

Do with this feedback as you wish. Thanks again for taking the time to explain this to me and link to the relevant places, and for the work you all do on this great language.

[jieyouxu]

I would like to nominate this for compiler triage meeting to maybe see if we want to amend the target policy docs to better reflect what compiler stability guarantees are made and what is explicitly not covered by compiler stability guarantees, as opposed to library API stability guarantees and language stability guarantees. And also especially about if there's any difference in stability guarantees (or the explicit lack thereof) for different-tiered compiler targets.

@rustbot label +I-compiler-nominated