Change:
/// `TaskDeps`. This is used when executing a 'normal' query /// (no `eval_always` modifier) Allow(&'a Lock<TaskDeps<K>>), <del> /// New dependencies are ignored. This is used when /// executing an `eval_always` query, since there's no </del> <ins> /// This is used when executing an `eval_always` query. We don't </ins> /// need to track dependencies for a query that's always <del> /// re-executed. This is also used for `dep_graph.with_ignore` </del> <ins> /// re-executed -- but we need to know that this is an `eval_always` /// query in order to emit dependencies to `DepNodeIndex::FOREVER_RED_NODE` /// when directly feeding other queries. EvalAlways, /// New dependencies are ignored. This is also used for `dep_graph.with_ignore`. </ins> Ignore, /// Any attempt to add new dependencies will cause a panic. /// This is used when decoding a query result from disk,

Discussion:
This is one of those ICEs that are terribly hard to minimize because they happen cache-dependently, [update: see below for repro instructions]. If nothing else, notice that there is a panic while trying to print the query stack; it might be desirable to look into making that not happen so as to be able to get more information. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --Occurred while running or . : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +A-incr-comp
On looking more closely at the backtrace, it seems that this error results from attempting to load corrupted (truncated) query cache files, and therefore it would be valuable to obtain a trace from the file having been written (assuming that they are truncated due to a panic during write; if they're silently corrupted that's even harder to notice). I will update this issue if I manage to catch such a case.
Looking at the first panic observed since a and it is still the above in , so it's not that I missed the writing event but that it didn't panic.
I have made some progress on reproducing the problem with a minimal incremental change (but not yet a minimal standalone code sample), and expressed some interest in looking at the problem, so I've published branches with the work I have so far. Repro steps: The second build will ICE. The differences between the two branches are shuffling code between modules, adding a module, and deleting a module; the code in them is as identical as it can be.
Note: I cannot reproduce this ICE on x86_64-unknown-linux-gnu with the latest nightly by default, but makes it ICE. <details<summarybacktrace</summary</details
I've created a new branch which slighly simplifies the diff application: ( at the time of writing).
I've tried to find out a bit more about this, but didn't get very far. From what I can tell: In the second session refers to the derived impl for . And refers to the const generic of that impl. It has the span of the CHUNKSIZE const generic of the type definition.

In the first session, as far as I can tell, the def-path refers to the , which also has a generic const. The query should not evaluate to green, but for some reason all of its dependencies are marked as green.
Maybe is too broken (it needed some fixing to show more than just DepKinds), but is it possible that has no dependencies at all during the first session?
It does indeed have no dependencies. I imagine that this is the culprit: I'm not really up-to-date with query feeding but this looks fishy. When a dep-node has no dependencies, it will trivially evaluate to green. Don't we need at least a dependency on the query that does the feeding? cc &
Given what we've learned about this bug, it's likely that this is purely about incremental compilation cache keying, i.e. neither state of the code is more likely to be miscompiled than the other, right? In other words, I as the author of the original code probably don't need to worry that I'm making my compiled code less reliable if I make the change that caused the ICE, as long as I after that point?
Yes, as far as I can tell, this is a bug in incremental compilation's dependency tracking and does not affect non-incremental builds.
Hey, I'm back with a repro! Thanks go out to , without which I would have never been able to minimize this. A one-command minimization is available at with . Basically: must be enabled. Running . Then applying Then running again panics. <details</detailsFor some strange reason I am unable to reproduce the changes when applying the diff in vscode via WSL. and work though.
I will unassign myself as I mostly assigned myself for the MCVE.
It looks like some things, like lowering to HIR, are run within a context, which leads to this call being ignored too -- and thus never making it into the we are trying to duplicate during . As a consequence, the feed queries in question go from explicitly "re-compute unconditionally" to effectively "re-use unconditionally" The reason seems to be that we . That's fine for those queries themselves because we make sure to re-compute those explicitly. But we fail to "inherit" the eval-always-ness to nested feed-queries. I'll look into fixing this some time this week.