Skip to content
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

Support non-stage0 check #81064

Merged
merged 3 commits into from
Jan 17, 2021
Merged

Conversation

Mark-Simulacrum
Copy link
Member

Seems to work locally - a full stage 1 check succeeds, building std (because we can't get away with checking it), and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 both checks and builds stage 1 std, and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why, but it doesn't seem worth digging in in too much detail).

Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g., compiler/rustc) explicitly.

r? @jyn514

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jan 16, 2021
@jyn514 jyn514 added the T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) label Jan 16, 2021
Copy link
Member

@jyn514 jyn514 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a lot better than my approach I think, but I'm worried it will break when cross-compiling, because ensure(Std) will build it for the target, not the host. Can you run x.py check --target x8_64-pc-windows-gnu or something to make sure this works?

src/bootstrap/check.rs Outdated Show resolved Hide resolved
src/bootstrap/flags.rs Show resolved Hide resolved
@rust-log-analyzer

This comment has been minimized.

@jyn514 jyn514 added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jan 16, 2021
@rust-log-analyzer

This comment has been minimized.

@Mark-Simulacrum Mark-Simulacrum force-pushed the support-stage1-check branch 2 times, most recently from 5f35f50 to 21e16e5 Compare January 16, 2021 14:55
@Mark-Simulacrum
Copy link
Member Author

Adjusted to support target checking (well, host checking, but it's not actually important).

@jyn514
Copy link
Member

jyn514 commented Jan 16, 2021

This is great, thanks so much :)

@bors r+

@bors
Copy link
Contributor

bors commented Jan 16, 2021

📌 Commit 53989e4 has been approved by jyn514

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Jan 16, 2021
m-ou-se added a commit to m-ou-se/rust that referenced this pull request Jan 16, 2021
…k, r=jyn514

Support non-stage0 check

Seems to work locally - a full stage 1 check succeeds, building std (because we can't get away with checking it), and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 *both* checks and builds stage 1 std, and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why, but it doesn't seem worth digging in in too much detail).

Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g., compiler/rustc) explicitly.

r? `@jyn514`
m-ou-se added a commit to m-ou-se/rust that referenced this pull request Jan 17, 2021
…k, r=jyn514

Support non-stage0 check

Seems to work locally - a full stage 1 check succeeds, building std (because we can't get away with checking it), and then checking the compiler and other tools. This ran into the problem that a unconditional x.py check in stage 1 *both* checks and builds stage 1 std, and then has to clean up because for some reason the rmeta and rlib artifacts conflict (though I'm not actually entirely sure why, but it doesn't seem worth digging in in too much detail).

Ideally we wouldn't be building and checking like that but it's a minor worry as checking std is pretty fast and you can avoid it if you're aiming for speed by passing the compiler (e.g., compiler/rustc) explicitly.

r? ``@jyn514``
bors added a commit to rust-lang-ci/rust that referenced this pull request Jan 17, 2021
Rollup of 13 pull requests

Successful merges:

 - rust-lang#79298 (correctly deal with late-bound lifetimes in anon consts)
 - rust-lang#80031 (resolve: Reject ambiguity built-in attr vs different built-in attr)
 - rust-lang#80201 (Add benchmark and fast path for BufReader::read_exact)
 - rust-lang#80635 (Improve diagnostics when closure doesn't meet trait bound)
 - rust-lang#80765 (resolve: Simplify collection of traits in scope)
 - rust-lang#80932 (Allow downloading LLVM on Windows and MacOS)
 - rust-lang#80983 (Remove is_dllimport_foreign_item definition from cg_ssa)
 - rust-lang#81064 (Support non-stage0 check)
 - rust-lang#81080 (Force vec![] to expression position only)
 - rust-lang#81082 (BTreeMap: clean up a few more comments)
 - rust-lang#81084 (Use Option::map instead of open-coding it)
 - rust-lang#81095 (Use Option::unwrap_or instead of open-coding it)
 - rust-lang#81107 (Add NonZeroUn::is_power_of_two)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 92dbfb5 into rust-lang:master Jan 17, 2021
@rustbot rustbot added this to the 1.51.0 milestone Jan 17, 2021
@jyn514 jyn514 mentioned this pull request May 1, 2021
matthiaskrgr pushed a commit to matthiaskrgr/rust that referenced this pull request Jul 30, 2022
Stage 1 check has been supported since rust-lang#81064.
 rust-lang#81064 changed the error message for this, but I don't think there's any reason we should prevent using it.
I tested locally and `keep-stage` works fine. Don't give a hard error when trying to use it.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this pull request Jul 30, 2022
…ulacrum

Support `x --keep-stage 0 check`

Stage 1 check has been supported since rust-lang#81064.
 rust-lang#81064 changed the error message for this, but I don't think there's any reason we should prevent using it.
I tested locally and `keep-stage` works fine.

r? `@Mark-Simulacrum`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants