-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Add x.py check --stage 1
#80952
Add x.py check --stage 1
#80952
Conversation
This is useful for several cases: - Checking changes to the standard library with `cfg(not(bootstrap))` - Checking platform-specific changes to the compiler. In particular, checking with stage 1 doesn't require having a cross-compiling C native toolchain, unlike building. - Testing newly added internal lints without having to rebuild rustc_middle twice It is also very easy to support.
(rust-highfive has picked a reviewer for you, use r? to override) |
Heh, that's an old issue 😄 - yeah it looks like this solves it. |
Yeah, I was triaging bootstrap issues a while ago and it popped up as something I'd want myself too 😆 |
I don't know why I thought this would be easy 🤦
|
Otherwise, we may not have MIR for the standard library available: ``` error: internal compiler error: compiler/rustc_mir/src/monomorphize/collector.rs:826:9: cannot create local mono-item for DefId(2:6820 ~ core[92cf]::fmt::{impl#2}::new_v1) ``` The current error after this change is ``` error[E0514]: found crate `chalk_derive` compiled by an incompatible version of rustc --> /home/joshua/.local/lib/cargo/registry/src/github.com-1ecc6299db9ec823/chalk-ir-0.36.0/src/lib.rs:13:5 | 13 | use chalk_derive::{Fold, HasInterner, SuperVisit, Visit, Zip}; | ^^^^^^^^^^^^ | = help: please recompile that crate using this compiler (rustc 1.51.0-dev) = note: the following crate versions were found: crate `chalk_derive` compiled by rustc 1.49.0-beta.1 (21dea46 2020-11-18): /home/joshua/rustc3/build/x86_64-unknown-linux-gnu/stage1-rustc/release/deps/libchalk_derive-843b3d0b9b865ca6.so ```
The job Click to see the possible cause of the failure (guessed by this bot)
|
Reporting on my progress so far, because I won't get it done tonight and I will definitely forget by tomorrow:
I tried implementing that just now and it went badly. I'm planning to wait to hear from @Mark-Simulacrum about whether this is a good idea first and whether there's a good way to do this without rewriting half of bootstrap. |
The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong, not what it was trying to do when it failed. cc rust-lang#80952 (comment)
Use better ICE message when no MIR is available The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong, not what it was trying to do when it failed. cc rust-lang#80952 (comment) cc `@jyn514`
Use better ICE message when no MIR is available The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong, not what it was trying to do when it failed. cc rust-lang#80952 (comment) cc ``@jyn514``
Use better ICE message when no MIR is available The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong, not what it was trying to do when it failed. cc rust-lang#80952 (comment) cc ```@jyn514```
Use better ICE message when no MIR is available The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong, not what it was trying to do when it failed. cc rust-lang#80952 (comment) cc ````@jyn514````
Use better ICE message when no MIR is available The ICE message is somewhat confusing and overly specific - the issue is that there's no MIR available. This should make debugging these ICEs easier since the error tells you what's actually wrong, not what it was trying to do when it failed. cc rust-lang#80952 (comment) cc `````@jyn514`````
This sort of makes sense, but I think I'd prefer folks use
I admit I don't fully follow this use case. I think there's very little platform-specific code in the cargo check phase of the compiler (indeed, other than differences between 32/64 bit, I can't obviously think of some). Maybe would be good to elaborate on this a bit.
This, on the other hand, is where the value is much more likely to be. I've filed #81064 to replace this PR, and set you as the reviewer. It looks like there's some configuration etc changes here which would be good to propagate, so feel free to push to my branch (or cherry-pick my commit, whatever). |
I think the point is not that the compiler is platform specific but that the code being compiled is platform specific. @Diggsey probably knows more than I do, but it seems useful to check libstd for various different targets without having to have a cross-compiling C toolchain installed. |
Anyway, closing this in favor of #81064, which I think is a better approach. |
Well, the intersection of cfg not bootstrap and target specific code is probably really low, so probably regular check should work ok for that. |
This is useful for several cases:
cfg(not(bootstrap))
(Warn when checkinglibrary/std
whenprofile = "compiler"
#78466)checking with stage 1 doesn't require a cross-compiling C native
toolchain, unlike building. (Add
x.py check --stage 1
#46955)rustc_middle twice (this is what finally made me decide to work on it: Don't make tools responsible for checking unknown and renamed lints #80524)
It is also very easy to support.
Closes #46955.