ICE: assertion failed: elem.index() < self.domain_size #103748
Comments
jruderman
added
C-bug
|
rust/compiler/rustc_middle/src/values.rs Line 189 in 4596f4f
rust/compiler/rustc_middle/src/query/mod.rs Line 326 in 4596f4f |
|
It looks like the parens are parsed as generic parameters for a type that doesn't have generic parameters? The simple fix is just check |
|
I think a reasonable fix is modifying the API for /// Returns `true` if `self` contains `elem`.
#[inline]
pub fn contains(&self, elem: T) -> bool {
- assert!(elem.index() < self.domain_size);
+ if elem.index() >= self.domain_size { return false; }
let (word_index, mask) = word_index_and_mask(elem);
(self.words[word_index] & mask) != 0
}It reasonable to add assertion |
|
Have a test on C++'s terminate called after throwing an instance of 'std::out_of_range'
what(): bitset::test: __position (which is 20) >= _Nb (which is 10)emm, it's better to keep it for |
|
@rustbot claim |
|
I'd be curious to know if we can maintain an invariant in the HIR that it does not contain generics that do not align with |
|
I considered removing the assert too, but I think it's better to have it since it exposes invalid assumptions as in this case. |
|
We should delay a bug (replacing the assertion) -- that's probably fine as long as it's understood why the |
|
@compiler-errors I have a real Dev experience when working on But there are many many other errors from later phases... |
|
If we can not get valid AST in parsing, later phases such as analysising will report out extra (mostly unhelpful) errors? |
The assertion is inside of the
I agree there are cases where rustc should quit sooner. But in general I think we have to err on the side of recover-and-continue if there is some possibility that more helpful errors may be emitted. |
This can happen. The parser should be more realistic on what it recovers and avoid errors from later passes that do not make sense. A few years back we would stop as soon as any error occurred in a given pass and avoid trying any further evaluation, and that was also a usability issue, because people would get a false sense of "how much work is left to fix". We shouldn't have a blanket evaluation stop, but maybe be more aggressive about pruning the AST when multiple parse errors have occurred. |
@camsteffen do you want to take over this issue? |
|
I can take a look. |
Rollup of 9 pull requests Successful merges: - rust-lang#100633 (Consider `#[must_use]` annotation on `async fn` as also affecting the `Future::Output`) - rust-lang#103445 (`#[test]`: Point at return type if `Termination` bound is unsatisfied) - rust-lang#103924 (Fix broken link in description of error code E0706) - rust-lang#104146 (Retry binding TCP Socket in remote-test-server) - rust-lang#104169 (Migrate `:target` rules to use CSS variables) - rust-lang#104202 (Fix ICE rust-lang#103748) - rust-lang#104216 (Don't ICE on operator trait methods with generic methods) - rust-lang#104217 (Display help message when fluent arg was referenced incorrectly) - rust-lang#104245 (Reduce default configuration's dependency upon static libstdcpp library (rust-lang#103606)) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Code
Error output
Full output including backtrace
Version
Regression
Regression from bba9785 (#100720)
Bisection details
bisected with cargo-bisect-rustc v0.6.4
searched nightlies: from nightly-2022-10-06 to nightly-2022-10-28
regressed nightly: nightly-2022-10-09
searched commit range: 8b0c05d...8796e7a
regressed commit: bba9785
Host triple: x86_64-apple-darwin
The text was updated successfully, but these errors were encountered: