Uh oh!
There was an error while loading. Please reload this page.
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
commented
Jan 12, 2021
(rust-highfive has picked a reviewer for you, use r? to override) |
jyn514
commented
Jan 12, 2021
Diggsey
commented
Jan 12, 2021
Heh, that's an old issue 😄 - yeah it looks like this solves it. |
jyn514
commented
Jan 12, 2021
Yeah, I was triaging bootstrap issues a while ago and it popped up as something I'd want myself too 😆 |
jyn514
commented
Jan 12, 2021
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
```rust-log-analyzer
commented
Jan 13, 2021
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`````
Mark-Simulacrum
commented
Jan 16, 2021
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. |
jyn514
commented
Jan 16, 2021
Anyway, closing this in favor of #81064, which I think is a better approach. |
Mark-Simulacrum
commented
Jan 16, 2021
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/stdwhenprofile = "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.