-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[bootstrap] Move the split-debuginfo
setting to the per-target section
#121754
Conversation
rustbot has assigned @Mark-Simulacrum. Use r? to explicitly pick a reviewer |
This PR modifies If appropriate, please update This PR modifies If appropriate, please update |
@rustbot author |
@rustbot ready |
☔ The latest upstream changes (presumably #122113) made this pull request unmergeable. Please resolve the merge conflicts. |
@ehuss can you say more about Cargo's automatic detection?
In particular it looks like we set -Zunstable-options in some cases if we don't think it's already stable, my assumption is that Cargo wouldn't do that, right? So until this is stable everywhere we would still need this custom support. r=me on the changes here in general though |
Cargo uses Indeed, it looks like |
24536a7
to
93a807f
Compare
Rebased. @rustbot ready |
@bors r+ |
[bootstrap] Move the `split-debuginfo` setting to the per-target section As described in rust-lang#112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple. This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example). However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`). rust-lang#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well. This PR does **not** implement `@ehuss's` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change. --- After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now. This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple. --- If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
…iaskrgr Rollup of 5 pull requests Successful merges: - rust-lang#121573 (unix_sigpipe: Add test for SIGPIPE disposition in child processes) - rust-lang#121754 ([bootstrap] Move the `split-debuginfo` setting to the per-target section) - rust-lang#122205 (ensure that sysroot is properly set for cross-targets) - rust-lang#122257 (mir-opt tests: don't run a different set on --bless; enable --keep-stage-std) - rust-lang#122272 (Subtree update of `rust-analyzer`) Failed merges: - rust-lang#122108 (Add `target.*.runner` configuration for targets) r? `@ghost` `@rustbot` modify labels: rollup
[bootstrap] Move the `split-debuginfo` setting to the per-target section As described in rust-lang#112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple. This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example). However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`). rust-lang#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well. This PR does **not** implement ``@ehuss's`` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change. --- After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now. This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple. --- If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
…iaskrgr Rollup of 8 pull requests Successful merges: - rust-lang#121754 ([bootstrap] Move the `split-debuginfo` setting to the per-target section) - rust-lang#122205 (ensure that sysroot is properly set for cross-targets) - rust-lang#122275 (disable OOM test in Miri) - rust-lang#122276 (io::Read trait: make it more clear when we are adressing implementations vs callers) - rust-lang#122286 (use Instance::expect_resolve() instead of unwraping Instance::resolve()) - rust-lang#122290 (MIR printing: print the path of uneval'd const) - rust-lang#122293 (diagnostics: Do not suggest using `#[unix_sigpipe]` without a value) - rust-lang#122297 (bootstrap: document what the triples in 'Build' mean) r? `@ghost` `@rustbot` modify labels: rollup
☔ The latest upstream changes (presumably #122331) made this pull request unmergeable. Please resolve the merge conflicts. |
Rebased. @rustbot ready |
☔ The latest upstream changes (presumably #122338) made this pull request unmergeable. Please resolve the merge conflicts. |
Rebased again. |
@bors r=Mark-Simulacrum,onur-ozkan |
…kingjubilee Rollup of 12 pull requests Successful merges: - rust-lang#121754 ([bootstrap] Move the `split-debuginfo` setting to the per-target section) - rust-lang#121953 (Add tests for the generated assembly of mask related simd instructions.) - rust-lang#122081 (validate `builder::PATH_REMAP`) - rust-lang#122245 (Detect truncated DepGraph files) - rust-lang#122354 (bootstrap: Don't eagerly format verbose messages) - rust-lang#122355 (rustdoc: fix up old test) - rust-lang#122363 (tests: Add ui/attributes/unix_sigpipe/unix_sigpipe-str-list.rs) - rust-lang#122366 (Fix stack overflow with recursive associated types) - rust-lang#122377 (Fix discriminant_kind copy paste from the pointee trait case) - rust-lang#122378 (Properly rebuild rustbooks) - rust-lang#122380 (Fix typo in lib.rs of proc_macro) - rust-lang#122381 (llvm-wrapper: adapt for LLVM API changes) r? `@ghost` `@rustbot` modify labels: rollup
Rollup merge of rust-lang#121754 - TimNN:split-target, r=Mark-Simulacrum,onur-ozkan [bootstrap] Move the `split-debuginfo` setting to the per-target section As described in rust-lang#112406, bootstrap currently applies the global `split-debuginfo` setting to all artifacts, irrespective of their target triple. This doesn't cause problems when the "build" triple defaults `split-debuginfo` to `off` (as is the case on Linux, for example). However, when the "build" triple has `split-debuginfo` enabled and additional target triples are configured, then artifacts for the additional triples will also be built with `split-debuginfo` (despite not necessarily supporting `split-debuginfo`). rust-lang#112406 mentions `riscv32imc-unknown-none-elf` as one target where this happens, and I've run into this with Wasm as well. This PR does **not** implement `@ehuss's` suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change. --- After this PR, anyone explicitly setting `rust.split-debuginfo` should update their configuration to specify the setting in the `target.<triple>` section, though `rust.split-debuginfo` will still be honored for the "build" triple for now. This PR changes the behavior when `rust.split-debuginfo` was **not** explicitly set **and** bootstrap is configured to cross-compile to a triple that has a different `split-debuginfo` than the "build" triple. --- If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in [`builder/tests.rs`](https://github.com/rust-lang/rust/blob/master/src/bootstrap/src/core/builder/tests.rs)).
As described in #112406, bootstrap currently applies the global
split-debuginfo
setting to all artifacts, irrespective of their target triple.This doesn't cause problems when the "build" triple defaults
split-debuginfo
tooff
(as is the case on Linux, for example).However, when the "build" triple has
split-debuginfo
enabled and additional target triples are configured, then artifacts for the additional triples will also be built withsplit-debuginfo
(despite not necessarily supportingsplit-debuginfo
).#112406 mentions
riscv32imc-unknown-none-elf
as one target where this happens, and I've run into this with Wasm as well.This PR does not implement @ehuss's suggestion that "bootstrap not try to guess how to configure split-debuginfo, and instead use cargo profiles to set it", because that seemed like a lot more significant change.
After this PR, anyone explicitly setting
rust.split-debuginfo
should update their configuration to specify the setting in thetarget.<triple>
section, thoughrust.split-debuginfo
will still be honored for the "build" triple for now.This PR changes the behavior when
rust.split-debuginfo
was not explicitly set and bootstrap is configured to cross-compile to a triple that has a differentsplit-debuginfo
than the "build" triple.If there's a reasonable way to add additional tests for this, please let me know (I didn't find any tests checking cargo arguments in
builder/tests.rs
).