ICE: assertion failed: bound_list_is_sorted(&bounds.projection_bounds) #28377
Comments
|
This is probably rooted in combine-language (Marwes/combine-language#4) though I have not been able to figure out what causes it. It has only affected me in the tests (and only some of the tests!). |
hawkw
changed the title
jdm
added
the
I-ICE
|
I'm trying to make sense of this, and it seems like a lot of the other issues for this ICE involve associated types. That's interesting, because my code currently doesn't make use of associated types. Either there are additional causes for this ICE, or it's hitting something in combine-language, I suppose? |
|
Got it. The sort-order of bounds depends on the order of DefIds. The order can change between a parent and child crate. crate foo: pub trait Foo { type FooT; }crate bar: pub trait Bar { type BarT; }crate baz: extern crate foo;
extern crate bar;
pub trait Baz : foo::Foo + bar::Bar {}
pub type BazT = Baz<FooT=(), BarT=u32>;crate main: extern crate bar;
extern crate foo; // note different order
extern crate baz;
fn main() {
let t: Option<Box<baz::BazT>> = None;
}I guess we should just sort the bounds-list. |
|
Found what was causing this in combine-language from @arielb1's hint, it wasn't the order of crate declarations though. For the types I implemented Parser for I had declared the associated types in the reverse order of how they were implemented/written in combine. After switching that (and fixing a few compilation errors which this ICE had hidden) I could compile the tests again. (See Marwes/combine-language@28d791b#diff-b4aea3e418ccdb71239b96952d9cddb6L55), The project where I used combine-language also had the same reverse order which seems to be the reason it did not run into the ICE. After updating that to use the version of combine-language with the fix it now ceases to compile (and fixing the order there makes it work again). Unforutunately, the next crate which includes the parser crate is now broken by the same error which I haven't figured out the cause for. |
|
Actually we also depend on crate aux: pub trait Trait {
type FooT;
type BarT;
}
pub type Object = Option<Box<Trait<FooT=(),BarT=()>>>;crate main pub type BarT = ();
pub type FooT = ();
extern crate aux;
fn main() {
let o: aux::Object = None;
} |
The sort key is a (DefId, Name), which is *not* stable between runs, so we must re-sort when loading. Fixes rust-lang#24063 Fixes rust-lang#25467 Fixes rust-lang#27222 Fixes rust-lang#28377
|
Not getting this ICE any longer from using combine-langauge, thanks for fixing this! |
Now that rust-lang/rust#28377 is fixed, the compiler no longer ICEs, so that’s nice.
|
Yeah, I can confirm, everything works fine on the latest nightly ( |
When trying to compile a crate using
cargo build,rustcfails with an unexpected panic. Cargo prints this message:I'm not sure which part of my code is causing the panic; so I don't have a code snippet to show. It's a reasonably large project and the error message doesn't reference a line number or source code file.
Here's a gist containing the source for the
mnemosyne-parsercrate that causes this error. Do note, however, that this code depends on the rest of my project and on @Marwes' library combine-language; the error could be a result of some interaction between my code and some of its dependencies.Meta
Backtrace:
Please let me know if there's any additional information I can provide!
The text was updated successfully, but these errors were encountered: