You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There is a second ICE once this one gets dealt with (I'll explain). I have some code checked in frankmcsherry/dataflow-join@03b82bc that has both a lib.rs and a lib-fail.rs. The two are basically the same except that the failing one uses associated types where the non-failing one doesn't.
It is a bit more complicated than that: there are trait objects of traits with both generic and associated types, and it seems (by commenting random things out) that if I need to end up with an associated type deep enough in some signature it goes sideways. Specifically, on line 91 of lib-fail.rs there is an instantiation of a type that wants a closure which captures a PE::RoutingFunction which implements Fn with an associated type as a reference argument; once I was able to comment that out (and things like it) everything stopped breaking. Or, because I want my code to work too, I change things to using generic parameters, which is what I actually did.
Anyhow, if you swap lib-fail.rs back in (and make the change to graph.rs indicated in the commit, basically exchanging generic parameters for associated types), and point it at frankmcsherry/timely-dataflow@f80dae6, it blows up with the following ICE:
Ok, with that fixed (changing associated types to generic parameters), I return to getting an pervasive ICE: "assertion failed: bound_list_is_sorted(&bounds.projection_bounds)". This often goes away if I toggle the Cargo.toml reference to timely back and forth between the github reference and a local copy. The two are identical, so no clue a) why it is ICEing, and b) why switching the source makes a difference, unless there is some stale info around. cargo clean occasionally does something helpful, but not always/usually.
I basically get this ICE all the time (most days). I'm a bit mystified why I seem to run in to it but no one else does, so if you have any tips on a likely cause I'm all ears. Happy to work around while you sort through other issues, but I'd love to understand how to avoid this.
The text was updated successfully, but these errors were encountered:
It's about five months old, so I'm sure it is "can't reproduce". Though, I'm happy to close it given that I don't see it anymore, and the other ICE seems to have been sorted out!
There is a second ICE once this one gets dealt with (I'll explain). I have some code checked in frankmcsherry/dataflow-join@03b82bc that has both a
lib.rs
and alib-fail.rs
. The two are basically the same except that the failing one uses associated types where the non-failing one doesn't.It is a bit more complicated than that: there are trait objects of traits with both generic and associated types, and it seems (by commenting random things out) that if I need to end up with an associated type deep enough in some signature it goes sideways. Specifically, on line 91 of
lib-fail.rs
there is an instantiation of a type that wants a closure which captures aPE::RoutingFunction
which implementsFn
with an associated type as a reference argument; once I was able to comment that out (and things like it) everything stopped breaking. Or, because I want my code to work too, I change things to using generic parameters, which is what I actually did.Anyhow, if you swap
lib-fail.rs
back in (and make the change tograph.rs
indicated in the commit, basically exchanging generic parameters for associated types), and point it at frankmcsherry/timely-dataflow@f80dae6, it blows up with the following ICE:Note: next ICE follows after the wall of text.
Ok, with that fixed (changing associated types to generic parameters), I return to getting an pervasive ICE: "assertion failed: bound_list_is_sorted(&bounds.projection_bounds)". This often goes away if I toggle the
Cargo.toml
reference totimely
back and forth between the github reference and a local copy. The two are identical, so no clue a) why it is ICEing, and b) why switching the source makes a difference, unless there is some stale info around.cargo clean
occasionally does something helpful, but not always/usually.Here is the stack track for this ICE:
I basically get this ICE all the time (most days). I'm a bit mystified why I seem to run in to it but no one else does, so if you have any tips on a likely cause I'm all ears. Happy to work around while you sort through other issues, but I'd love to understand how to avoid this.
The text was updated successfully, but these errors were encountered: