-
Notifications
You must be signed in to change notification settings - Fork 13.3k
ICE while bootstrapping (./x.py build) #2 #60228
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
@matthiaskrgr does this reproduce reliably for you? Is that still true if you do a fresh checkout (so as not to have an incremental history?) We're trying to figure out if this is an incremental bug or what. |
Marking P-high so can keep track of this, but we are still trying to ascertain just what's going on. |
does I'm currently trying something like
to see if that reliably reproduces the crash. |
@matthiaskrgr should be good enough, yes |
Ok, I poked around in the git reflog and got this recipe
I was able to reproduce this in 2 out of 2 attempts :) |
Probably #60190 then I suspect? cc @alexcrichton and @nnethercote Might also be #56278 but I doubt it. |
This doesn't look like #60190 to me at first glance, but I could of course be wrong. Given that it requires incremental build state it could just be a preexisting bug that hasn't been hit yet. |
Sure, yeah -- that deduction was purely based on most likely PRs from the rollup in 8a44125. |
(I'll try to look at this early this week.) |
okay I have managed to replicate the problem locally via the above recipe. Continuing investigation. (Trying to decide whether to expend effort on trying to reduce to a smaller test input...) |
I have observed the following:
To be clear, I do not think this implies a bug in 48cb6be itself. I suspect it is just exposing a bug somewhere in incremental compilation. I'm going to try to test that theory by narrowing the changeset 48cb6be itself. |
another data point: if you: then you see the same ICE error. Update: this may have been obvious, but I wanted to make sure I made note of it: if you take this approach, you cannot use
the build completed "successfully", thus failing to replicate the problem. |
#59945 might be related |
potentially new data point: as an experiment, I tried redoing the experiment above, but applied to the current master (c2e49bf), by building, then applying this patch, and then building again. (click to see patch)diff --git a/src/librustc/ich/impls_syntax.rs b/src/librustc/ich/impls_syntax.rs
index 4e5718cc5ef..1c70b933f86 100644
--- a/src/librustc/ich/impls_syntax.rs
+++ b/src/librustc/ich/impls_syntax.rs
@@ -117,6 +117,7 @@ impl_stable_hash_for!(enum ::rustc_target::spec::abi::Abi {
impl_stable_hash_for!(struct ::syntax::attr::Deprecation { since, note });
impl_stable_hash_for!(struct ::syntax::attr::Stability {
+ _unused,
level,
feature,
rustc_depr,
diff --git a/src/librustc/middle/stability.rs b/src/librustc/middle/stability.rs
index abcf164cda6..a98200268ec 100644
--- a/src/librustc/middle/stability.rs
+++ b/src/librustc/middle/stability.rs
@@ -442,6 +442,7 @@ impl<'a, 'tcx> Index<'tcx> {
const_stability: None,
promotable: false,
allow_const_fn_ptr: false,
+ _unused: false,
});
annotator.parent_stab = Some(stability);
}
diff --git a/src/libsyntax/attr/builtin.rs b/src/libsyntax/attr/builtin.rs
index 65ca96afab1..f0e692cb850 100644
--- a/src/libsyntax/attr/builtin.rs
+++ b/src/libsyntax/attr/builtin.rs
@@ -116,6 +116,8 @@ pub struct Stability {
pub promotable: bool,
/// whether the function has a `#[rustc_allow_const_fn_ptr]` attribute
pub allow_const_fn_ptr: bool,
+ /// new unused field for reproducing ICE
+ pub _unused: bool,
}
/// The available stability levels.
@@ -361,6 +363,7 @@ fn find_stability_generic<'a, I>(sess: &ParseSess,
const_stability: None,
promotable: false,
allow_const_fn_ptr: false,
+ _unused: false,
})
}
(None, _, _) => {
@@ -424,6 +427,7 @@ fn find_stability_generic<'a, I>(sess: &ParseSess,
const_stability: None,
promotable: false,
allow_const_fn_ptr: false,
+ _unused: false,
})
}
(None, _) => { Two interesting things happened:
(click to see more complete log suffix)
From the whole build log, the two (and only two) specific rustc-demangle crates that I see arising are:
|
In a more recent attempt to run the above experiment (and, at least this time, using a locally built Here is my [llvm]
[build]
submodules = true
extended = true
tools = ["cargo", "rls", "clippy", "rustfmt", "analysis", "src"]
sanitizers = true
profiler = true
low-priority = true
rustc = "/home/pnkfelix/Dev/Mozilla/issue60228/rust-60228-bootstrap/build/x86_64-unknown-linux-gnu/stage1/bin/rustc"
[install]
[rust]
[target.x86_64-unknown-linux-gnu]
[dist] Also, AFAICT, the |
I'm going to be taking a break for a few months. I do not know if this issue should remain P-high. If it is to remain P-high, then someone else should be added to the assignee list (or outright replace me as the assignee.) But its possible we should just downgrade this issue to P-medium. |
triage: downgrading to P-medium. |
I have not observed this ICE while bootstrapping in a while now and would not object closing this issue. |
I think this is a duplicate of #76720. |
repo is @ 8a44125
config.toml:
backtrace:
EDIT(@eddyb): hid log & backtrace in
<details>
(click to open build log)
(click to open backtrace)
The text was updated successfully, but these errors were encountered: