Do not build nightly-only tools on beta/stable CI #74709
Labels
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-infra
Relevant to the infrastructure team, which will review and decide on the PR/issue.
Comments
JohnTitor
added
the
T-infra
jonas-schievink
added
the
T-bootstrap
boklm
pushed a commit
to boklm/tor-browser-build
that referenced
this issue
Jan 22, 2021
We pick up the latest (currently) Rust stable version, 1.48.0. miri fails to compile (even though the build succeeds) which is okay-ish. See: rust-lang/rust#79582 and rust-lang/rust#74709 for more details. It's not clear why exactly we need to specify the host as a target now, too. But I guess previously things just worked by chance. The correct thing to do is to specify `x86_64-unknown-linux` as target, too, given that we are targetting it, e.g. with `cbindgen`. Note: we could think about specifying `--host` here too, but it seems we can avoid that extra configure argument, see: rust-lang/rust#76990.
waybackarchiver
pushed a commit
to tor-actions/tor-browser-build
that referenced
this issue
Apr 11, 2021
We pick up the latest (currently) Rust stable version, 1.48.0. miri fails to compile (even though the build succeeds) which is okay-ish. See: rust-lang/rust#79582 and rust-lang/rust#74709 for more details. It's not clear why exactly we need to specify the host as a target now, too. But I guess previously things just worked by chance. The correct thing to do is to specify `x86_64-unknown-linux` as target, too, given that we are targetting it, e.g. with `cbindgen`. Note: we could think about specifying `--host` here too, but it seems we can avoid that extra configure argument, see: rust-lang/rust#76990.
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 30, 2021
…t-of-84158, r=Mark-Simulacrum backport: move new c abi abort behavior behind feature gate This is a backport of PR rust-lang#84158 to the beta branch. The original T-compiler plan was to revert PR rust-lang#76570 in its entirety, as was attempted in PR rust-lang#84672. But the revert did not go smoothly (details below). Therefore, we are backporting PR rust-lang#84158 instead, which was our established backup plan if a revert did not go smoothly. I have manually confirmed that this backport fixes the luajit issue described on issue rust-lang#83541 <details> <summary>Click for details as to why revert of PR rust-lang#76570 did not go smoothly.</summary> It turns out that Miri had been subsequently updated to reflect changes to `rustc_target` that landed in PR rust-lang#76570. This meant that the attempt to land PR rust-lang#84672 broke Miri builds. Normally we allow tools to break when landing PR's (and just expect follow-up PR's to fix the tools), but we don't allow it for tools in the run-up to a release. (We shouldn't be using that uniform policy for all tools. Miri should be allow to break during the week before a release; but currently we cannot express that, due to issue rust-lang#74709.) Therefore, its a lot of pain to try to revert PR rust-lang#76570. And we're going with the backup plan. </details> Original commit message follows: ---- *Background* In rust-lang#76570, new ABI strings including `C-unwind` were introduced. Their behavior is specified in RFC 2945 <sup>[1]</sup>. However, it was reported in the #ffi-unwind stream of the Rust community Zulip that this had altered the way that `extern "C"` functions behaved even when the `c_unwind` feature gate was not active. <sup>[2]</sup> *Overview* This makes a small patch to `rustc_mir_build::build::should_abort_on_panic`, so that the same behavior from before is in place when the `c_unwind` gate is not active. `rustc_middle::ty::layout::fn_can_unwind` is not touched, as the visible behavior should not differ before/after rust-lang#76570. <sup>[3]</sup> ### Footnotes 1.: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md 2.: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/Is.20unwinding.20through.20extern.20C.20UB.3F/near/230112325 3.: https://github.com/rust-lang/rust/pull/76570/files#diff-b0320c2b8868f325d83c027fc5d71732636e9763551e35895488f30fe057c6e9L2599-R2617 [1]: https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md [2]: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/Is.20unwinding.20through.20extern.20C.20UB.3F/near/230112325 [3]: https://github.com/rust-lang/rust/pull/76570/files#diff-b0320c2b8868f325d83c027fc5d71732636e9763551e35895488f30fe057c6e9L2599-R2617
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Currently, we build nightly-only tools such as Miri even on beta/stable CI, only to then ignore whether they build or not. That seems like a waste. We certainly do that for the tools builders (that also run the tests); I do not know if we also do it for dist builders (that just build the tools to put them into rustup packages).
#74389 is the beginning of fixing that, but I got stuck due to not knowing enough about rustbuild.
The text was updated successfully, but these errors were encountered: