Add a new wasm32-wasip1 target to rustc

[alexcrichton]

This commit adds a new target called wasm32-wasip1 to rustc. This new target is explained in these two MCPs:

• Rename wasm32-wasi target to wasm32-wasi-preview1 compiler-team#607
• Smooth the renaming transition of wasm32-wasi compiler-team#695

In short, the previous wasm32-wasi target is going to be renamed to wasm32-wasip1 to better live alongside the new wasm32-wasip2 target. This new target is added alongside the wasm32-wasi target and has the exact same definition as the previous target. This PR is effectively a rename of wasm32-wasi to wasm32-wasip1. Note, however, that as explained in rust-lang/compiler-team#695 the previous wasm32-wasi target is not being removed at this time. This change will reach stable Rust before even a warning about the rename will be printed. At this time this change is just the start where a new target is introduced and users can start migrating if they support only Nightly for example.

[rustbot]

r? @compiler-errors

(rustbot has picked a reviewer for you, use r? to override)

[rustbot]

This PR modifies config.example.toml.

If appropriate, please update CONFIG_CHANGE_HISTORY in src/bootstrap/src/utils/change_tracker.rs.

These commits modify compiler targets.
(See the Target Tier Policy.)

[alexcrichton]

I'll note that this file started as an exact copy of the one from wasm32_wasi.rs but I took the liberty of updating this (now very old) comment while I was here.

[compiler-errors]

r? @wesleywiser

[bors]

☔ The latest upstream changes (presumably #120496) made this pull request unmergeable. Please resolve the merge conflicts.

[wesleywiser]

@bors r+

[bors]

📌 Commit e7c1b37 has been approved by wesleywiser

It is now in the queue for this repository.

[syrusakbary]

I'm extremely concerned about renaming wasm32-wasi to wasm32-wasi-preview1, if then we do use the this target in the future for something else.
Why? this will break compatibility and many workloads that assume that the wasm32-wasi target is indeed the Preview 1 implementation.

I would recommend keep using wasm32-wasi for Preview 1 and create a new target for Preview 2 (wasm32-wasi-preview2) without actually having to break compatibility, specially given that preview 2 is a preview and not final version of WASI. / cc @alexcrichton

Note

I would have commented on the original MCP issue, but I'm actually blocked to perform that action

[wesleywiser]

@syrusakbary a new target for wasm32-wasi-preview2 is being created, wasm32-wasi is not being repurposed to target WASI preview 2. My understanding is that the eventual plan is for wasm32-wasi to target WASI (preview nothing) when that is stabilized but there is currently no timeline for that to happen.

[alexcrichton]

Actually we've had some further discussion about this target at the BA meetup currently happening today. We might want to propose a different name for this target given how the WASI subgroup may decide to drop the "preview" terminology when talking about WASI versions.

While that discussion is settling and we figure out how best to react to that could this PR be removed from the queue? I'll be sure to follow-up here afterwards after we settle on the naming for sure. I apologize for this coming up late in the process!

[rust-timer]

Finished benchmarking commit (d18480b): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	-	-	0
Improvements ✅ (primary)	-3.5%	[-5.5%, -2.1%]	13
Improvements ✅ (secondary)	-2.9%	[-4.8%, -0.5%]	59
All ❌✅ (primary)	-3.5%	[-5.5%, -2.1%]	13

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	2.4%	[2.1%, 2.8%]	4
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 645.218s -> 643.087s (-0.33%)
Artifact size: 175.01 MiB -> 174.99 MiB (-0.01%)

[alexcrichton]

Filling in the schedule from the MCP gives:

date	Rust Stable	Rust Beta	Rust Nightly	Notes
2024-02-08	1.76	1.77	1.78	add support for wasm32-wasi-preview1 (1, 2)
2024-03-21	1.77	1.78	1.79
2024-05-02	1.78	1.79	1.80
2024-06-13	1.79	1.80	1.81	warn on wasm32-wasi (4)
2024-07-25	1.80	1.81	1.82
2024-09-05	1.81	1.82	1.83
2024-10-17	1.82	1.83	1.84	remove wasm32-wasi (5)
2024-11-28	1.83	1.84	1.85
2025-01-09	1.84	1.85	1.86	wasm32-wasi is now gone on all release channels

I'll schedule a notification for myself in mid-Junue to land the change to warn on usage of wasm32-wasi.

[eminence]

2024-01-09 wasm32-wasi is now gone on all release channels

This should read 2025, right?

[alexcrichton]

Oops, yes

[alexcrichton]

@rustbot label +relnotes

I want to additionally write at least a small blurb here for the release notes for the future, and I'll also work with @yoshuawuyts to update rust-lang/blog.rust-lang.org#1099 for a longer-form post as well perhaps:

This release introduces a new compiler target: wasm32-wasip1. This target is the exact same as the wasm32-wasi target except in name. Originally proposed in rust-lang/compiler-team#607 the rollout plan for this new target was later adapted in rust-lang/compiler-team#695. In short this new target will, in 2025, replace the wasm32-wasi target. The wasm32-wasi target is going to remain until the Rust 1.84 stable release in January 2025, giving users a chance to transition from the wasm32-wasi name to wasm32-wasip1. Users of wasm32-wasi will start to receive warnings about the rename in Rust 1.81 to be released in September 2024 before the final removal.

The summary of the motivation for this rename is that the WASI subgroup has approved a new 0.2.0 release of the WASI specifications which is a major change from the previous version. Support for "WASIp2" is present on Nightly Rust in the form of wasm32-wasip2 and the wasm32-wasip1 target name more closely aligns with the future development of WASI.

[syrusakbary]

Hey @alexcrichton, the comment you did yesterday is the first time I heard that the wasm32-wasi target will be removed (I assume, with the intention, to later point to another version) starting Jan 2025.
This decision will break many CI workloads, as I actively commented many times in this thread.

Where was this discussed publicly? I'd expect a decision of such caliber to at least be voted publicly in a WASI meeting where there are many participants and users that can chime with their opinion.

Actually we've had some further discussion about this target at the BA meetup currently happening today

Upon further reading the comments on this issue, I also realized that the decision was taken in a private Bytecode Alliance meetup, where people belonging to the WASI group can't publicly vote for things. Please note that I'm part of the WASI and WebAssembly Community Groups, and this was never discussed there.

I'm quite concerned that decisions of such magnitude being taken behind closed doors without involving the people actually using the technology.
I'd like to revisit this decision, because, again... I think it will impact negatively many workloads.

[eminence]

This decision will break many CI workloads

It seems like 10 months is plenty of time to make the migration from wasm32-wasi to wasm32-wasip1 (which I think is just a simple textural search and replace). Are you saying that is not enough time for you and your projects?

[bjorn3]

On the Rust side rust-lang/compiler-team#607 was the initial MCP (major change proposal) for renaming the wasm32-wasi target. It was seconded April last year. Later rust-lang/compiler-team#695 was opened to suggest extending the period over which the transition happens and this was also accepted. All MCP's are publicly discussed on the rust-lang zulip, but I realize that not everyone watches this location. When the original MCP was opened, rust-lang/blog.rust-lang.org#1099 was also opened to notify users about the upcoming changes. It hasn't been merged yet, a request has been made to update it for the new schedule a couple of hours ago.

On the bytecodealliance side I found a public heads up on zulip right after the second MCP was accepted. I'm not aware of any closed door discussion about this change. (I couldn't find anything about it in the public meeting minutes for wasmtime and I have only actually attended the wasmtime meeting once or twice long before wasip2 existed.)

There has been a suggestion to teach rustc about renamed targets to give a more helpful error message that indicates that the target was renamed : #110596 (comment) This hasn't been implemented yet though.

[alexcrichton]

To add to what others have already mentioned:

Where was this discussed publicly?
[...]
the comment you did yesterday is the first time I heard that the wasm32-wasi target will be removed (I assume, with the intention, to later point to another version) starting Jan 2025.

As @bjorn3 mentioned, this was discussed in various places before. That includes this very PR, where despite what you're saying now, on January 31 you asked about the same issue, and got a reply to the same effect from Wesley.

I also realized that the decision was taken in a private Bytecode Alliance meetup

This is not correct and is a mischaracterization of what happened. At a meetup we had an idea so I put this PR on hold to align with the naming scheme Go established. Later in an official WASI SG meeting, which the notes say you were not present at, the naming of "WASIpX" was discussed and agreed upon. I've noted on this PR as to the rationale here and I've summarized the subgroup's consensus.

I'd expect a decision of such caliber to at least be voted publicly in a WASI meeting

I would like to clarify what's happening here to make sure we're all clear. The WASI subgroup does not make decisions for the Rust project, and can only make recommendations. Rust project decisions are made through MCPs, as @bjorn3 has linked.

being taken behind closed doors

I would encourage you to assume good faith here instead of assuming bad faith. As laid out above, no decisions have been made behind any closed doors, especially in the BA. And nor could they have been, because the Rust project wouldn't be beholden to any decisions made in the BA.

Your comment above, and historical comments on this PR and a sibling PR, indicate to me at least that you're not reading very deeply into decisions/comments being made. I think I've linked the MCPs in many places now for you personally as you keep asking questions that are answered in them. To put it bluntly it feels like you're pointing at a bunch of open doors and claiming they're all closed.

[syrusakbary]

I think I mentioned this on other issues, but perhaps it was missed.

I was not able to comment on the original MCP issue (and I still am unable): rust-lang/compiler-team#607 (please see screenshot)

---

I don't assume bad faith at all. I just think removing the wasm32-wasi target in less than a year is not wise and will break many workloads. This also implies that the wasm32-wasi in Rust will be actually different than the same target in Clang when using libc (Preview 1). This is not my opinion, is just the reality.

I'm also aware that I'm not the only one that thinks this decision is unwise. I'm listening you, but I don't think the opinions are being heard, for something that I think is quite important, as I believe affect the whole WASI community.

So, if you were in the shoes of the ones that think that removing the wasm32-wasi target in Rust is not the right path to take, how do you think would be best to proceed? @alexcrichton @bjorn3

[alexcrichton]

These changes have been discussed over months here, and are in line with the recommendation the WASI subgroup made. While maybe you weren't able to attend the meeting in which this recommendation was discussed, nobody else raised any concerns. Nor did you raise these concerns to the WASI subgroup after the meeting notes were published.

I think you're right that consistent naming of these targets is desirable. My understanding is that that is exactly why the WASI subgroup made this recommendation, choosing Go's target naming as the one to unify on. Based on that, work is also ongoing to change the naming of wasi-sdk's target.

And I will reiterate that despite what you're saying, you've clearly been aware of these changes for a while now. I don't know why you're not able to comment on the MCP, but you could have taken lots of other steps: for example you could reach out to the Rust project to find out why you can't comment. You could also have replied when Wesley clarified the plan to you in January. And generally, you could have put more effort into making an argument than simply saying that you're against this change and vaguely alluding to other people who're opposed to it.

You have been asked for more details on your argument, but haven't replied, so I'll ask again: is the transition period here not long enough? You have claimed multiple times that this will "break many workloads" but have not attempted to explain why with respect to a long transition period. I think it's safe to say that we're all aware that simply removing wasm32-wasi is not an option, which is why there's a transition plan in place.

Or are you saying that the Rust project shouldn't ever follow the WASI subgroup's recommendation? If so, that would lead to a situation where a Rust target called wasm32-wasi would be about something different from WASI's design as worked on by the subgroup. If, however, you're instead disagreeing mainly with the recommendation itself, then I would suggest that this isn't the right forum to express that disagreement, and that you should see if you can make compelling arguments to the WASI subgroup to revisit this decision.

[syrusakbary]

I think you're right that consistent naming of these targets is desirable

I'm happy that we can agree on this.

You could also have replied when Wesley to you in January

Wesley's comment was mainly about wasm32-wasi-preview2, which is why I did not reply before. Since it was mentioned that "there is currently no timeline for that [repurposing wasm32-wasi] to happen", it was easy to assume that the wasm32-wasi target was not actually going to break, which is my main reason for concern.

is the transition period here not long enough?

This question is fully missing the point.
Let me explain why: the issue is not the transition period length, the issue is about having a breaking change in the target name, moving away from what clang also considers as wasm32-wasi (being preview 1) and breaking existing compatibility with already existing Rust workloads that target wasm32-wasi.
This are my main arguments. And unfortunately I don't see those debated or discussed anywhere.

Or are you saying that the Rust project shouldn't ever follow the WASI subgroup's recommendation?

Please let me know where I can find that the WASI subgroup recommended as a whole to remove wasm32-wasi, because maybe I missed it when reading the meeting notes. The whole meeting notes are mainly about Preview 2 plan, and a bit of Preview 3.
Regarding wasm32-wasi I only see a single comment from Pat Hickey referencing it, but one can easily imply that there not a specific date or plan in mind, is not definitive, nor it can be interpreted that the WASI subgroup made that decision as a whole ("one day wasm32-wasi may be removed or changed to mean WASI 1.0").

Of course, I don't know if more things were discussed in that meeting that are not reflected in the meeting notes, but that shall be even a bigger reason for concern. Because a question as important as removing the wasm32-wasi target should have been planned so everyone that have an opinion can plan to attend the meeting and reflect their opinion with their vote. I hope we can agree on that.

In any case, I do reiterate, removing the wasm32-wasi target in Rust is a big concern for the reasons described before. So, being where we are today, how do you suggest we can move forward?

[jeffparsons]

the issue is not the transition period length, the issue is about having a breaking change in the target name

Even as a relatively casual observer, it has been clear to me for about a year that the general consensus was that wasm32-wasi should eventually be freed up to make way for "WASI 1.0". You might even say that using it to refer to "preview 1" is regarded, in retrospect, as having been a mistake.

This decision has not been made lightly; nobody wants breaking changes. However, I doubt you will find many people who agree with your strict "no breaking target name change ever" stance. There are benefits of freeing up wasm32-wasi, and the cost will be relatively small. Specifically, it will:

• Only require superficial changes to code to adjust for — in most cases, literally just a string search and replace.
• Only affect people who are rebuilding code that targets preview1, who are also upgrading to new Rust releases.

I am struggling to imagine who these people are who are actively upgrading their Rust toolchain, but who can not comfortably replace the string "wasm32-wasm" with "wasm32-wasip1" some time in the space of about a year.

Perhaps if you could describe a specific difficult scenario you have in mind, it might shed light on why you consider this to be such a big deal.