-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
ICE while bootstrapping (./x.py build) #2 #60228
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: