Update bootstrap to use -Zembed-metadata=no instead of -Zno-embed-metadata#159781
Update bootstrap to use -Zembed-metadata=no instead of -Zno-embed-metadata#159781dpaoliello wants to merge 1 commit into
Conversation
|
cc @bjorn3 |
rustbot
added
S-waiting-on-review
|
r? @mejrs rustbot has assigned @mejrs. Use Why was this reviewer chosen?The reviewer was selected based on:
|
This comment has been minimized.
This comment has been minimized.
|
Ah, this is annoying. On stage0/beta Cargo, the old flag is still used, while if we use the in-tree stage1+ Cargo, we have to use the new flag. |
|
Maybe we can just temporarily stop using this flag, although I'm not sure whether bootstrap can deal with both the flag being on and off. |
|
We can check for the |
This comment has been minimized.
This comment has been minimized.
| if matches!(mode, Mode::Std) { | ||
| cargo.arg("-Zembed-metadata=no"); | ||
| // The `-Zembed-metadata` flag was renamed from `-Zno-embed-metadata`. | ||
| if build_compiler_stage == 0 { |
There was a problem hiding this comment.
The same cargo is used for all stages, so checking build_compiler_stage is not correct. local-rebuild should work though. That is what is used to indicate that the bootstrap toolchain (and thus cargo) matches the in-tree one (or is at most a patch release away)
…adata The recent Cargo submodule update picked up <rust-lang/cargo#17149> However, bootstrap was still using the old name, resulting in: ``` Building stage1 library artifacts (stage1 -> stage1, arm64ec-pc-windows-msvc) error: unknown `-Z` flag specified: no-embed-metadata ``` Fix is to switch to the rename. I also removed the diff in the Cranelift setup script, since they must have already hit this issue and no longer need the workaround.
|
Thank you! Let's try. @bors r+ rollup=iffy |
rust-bors
Bot
added
S-waiting-on-bors
6 participants
The recent Cargo submodule update picked up rust-lang/cargo#17149
However, bootstrap was still using the old name, resulting in:
Fix is to switch to the rename.
I also removed the diff in the Cranelift setup script, since they must have already hit this issue and no longer need the workaround.