@WG-prioritization/alerts issue #80336 has been requested for prioritization.
I don't have enough context to judge this one, any opinion @WG-prioritization ? There's also a thorough analysis and a comment about not being easy to reduce it to an mcve.
But it seems that this ICE is blocking a compilation of code pulled from that repo, so I feel this should be investigated closely. my uneducated guess would say P-high at least
the explanation by @Aaron Hill seems to imply that the current eval cache is unsound, even if we don't yet know if that unsoundness can actually be triggered.
I would do
P-high given that it’s seemingly not easy to actual trigger but it needs to be actively investigated
This only happens with
that's another good question.
Ill also mention the ICE group if anyone can have a look and try to reduce this a little bit
(maybe also try it on a different rust branch - no evidence yet the issue happening on other than nightly)
Issue #80336's prioritization request has been removed.
if it also happen on other than nightlies
IIUC this ICE happens because of the
-Z incremental-verify-ich? So trying to reproduce on e.g. stable is not going to work
oh I see, is that because
incremental-verify-ich is a nightly only flag? (tried to search for that flag but couldnt find anything useful...)
I think the question of whether it can reproduce on e.g. beta is important if it turns out this issue is unsound
mh, I was able to reproduce in a different repo (rust analyzer) on x86, so probably unrelated to wasm in particular
and yes, it also happens on beta
if I force
-Zincremental-verify-ich to be enabled
If you can post a comment on the issue with your findings, that would be great :heart:
also happens on stable 1.48.0
thread 'rustc' panicked at 'found unstable fingerprints for evaluate_obligation(4aebcd058ee1a9be-c5a25d2e61d4dbbb)', /rustc/7eac88abb2e57e752f3302f02be5f3ce3d7adfb4/compiler/rustc_query_system/src/query/plumbing.rs:555:5 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: rustc 1.48.0 (7eac88abb 2020-11-16) running on x86_64-unknown-linux-gnu note: compiler flags: -Z incremental-verify-ich=yes -C embed-bitcode=no -C debuginfo=0 -C incremental --crate-type lib note: some of the compiler flags provided by cargo are hidden error: could not compile `ide_db`
Can that happen in 1.47.0? If not we might be able to bisect the bug to a specific commit
also happens in
1.46 as well...
stopped going deeper now
Thanks a lot!
Hmm, I was wondering if this bug could deserve
@apiraino IIRC you said tomorrow's agenda is quite light? Could we add this issue maybe?
The goal being to determine if this bug can cause actual unsoundness
I see some investigation here :-) thanks a lot @matthiaskrgr great work!
yes, I think we can ask the team is the
-Z incremental-verify-ich flag rings a bell. perhaps the question they will have is, if that can be reproduced on a smaller case, but that can be investigated later (I think)
by the way @matthiaskrgr on the issue I read
RUSTFLAGS="-Zincremental-verify-ich=yes" cargo build instead of
-Z incremental.... is that a typo or is that irrelevant to the compilation? (apologies for the stupidest question ever)
you mean the space?
It doesn't matter, rustc parses both
right, the space :point_up:
@apiraino wait, I'm confused. Does the
-Z incremental-verify-ich actually perform optimizations?
tried to gather infor on that flag earlier but failed to get some context :-(
The description for the flag in
verify incr. comp. hashes of green query instances (default: no)
I think it just verifies the cache
So the issue is not the flag, it's the way rustc caches stuff, with or without the flag
ah right. but it's a nightly only flag, right?
But if, as I inferred from Aaron's analysis, rustc's handling of regions in the ICH is wrong, this issue will appear with or without the flag, and on stable as well
with or without the flag
I don't follow this part: iiuc the issue is about that flag causing the ICE, correct?
But IIUC it doesn't change anything about the way the ICH is generated, it just verifies it by running checks
so it's required to reproduce the issue. But it's also a nightly-only flag. so why matthiaskrgr reproduced also on "1.47 and 1.46"?
What I think is scary about this issue is not the ICE
It's the possibility that the incremental cache is not implemented correctly and could lead to unsoundness
ok. I'm just asking because I think in the past "nightly-only" issues (caused by unstable features still far from being stabilized) were not high in priority (If I recall correctly)
but I agree with the general reasoning exposed here
Do you want me to write the agenda entry, if that can help you?
please feel free to add what do you think is appropriate :)
the ice also reproduces inside the
regex crate (has only little deps and is smaller). I was able to trigger it by adding an empty line in some function :thinking:
got it down to a couple of lines
guys what are you doing here?
get out and turn off the computer :D
fireworks were cancelled here :P
Yes it’s also forbidden in Germany
in florida it's allowed for farmers or anyone who says they're a farmer and has the money to pay for it :joy:
oh wait I take it back, they just legalized it for holidays http://www.northescambia.com/2020/12/fireworks-are-legal-for-new-years-in-florida