Stream: t-compiler

Topic: incremental-hash-collision


oli (Oct 20 2018 at 16:24, on Zulip):

@mw I'm getting

thread 'main' panicked at 'Forcing query with already existing DepNode.] 17/30: core
- query-key: Canonical { variables: [], value: ParamEnvAnd { param_env: ParamEnv { caller_bounds: [], reveal: UserFacing }, value: Binder(TraitPredicate(<[u32; 10] as marker::Sized>)) } }
- dep-node: EvaluateObligation(fa1a5a9b41e70025-8629dce568141d82)', librustc/ty/query/plumbing.rs:531:9

on a branch of mine. Following the assert to the code leads me to a message stating that either the dep graph code is broken (which I did not touch), or that there's a hash collision. I did touch ConstValue, which is the 10 in [u32; 10] in the above error. All I did was remove a variant from the ConstValue enum, meaning the stable hash code also removed the arm handling it.

Do you have any tips for debugging this ICE? (it's happening direcltly when compiling core, and during wellformedness checks of a static item's type, which is the array type you see above)

oli (Oct 21 2018 at 10:24, on Zulip):

Another datapoint speaking for hash collision: https://github.com/rust-lang/rust/blob/7db82ccd765cbfe55c3d8a2c434bc6f9b986843d/src/libcore/num/flt2dec/strategy/dragon.rs#L26 is failing to typeck the type [u32; 10] but according to my logging, the item right before that, with the same type, does typeck

oli (Oct 21 2018 at 10:24, on Zulip):

So.... I presume that the issue is that we get a hash collision because they are the same, but since their alloc IDs differ, we don't get equality by the Eq impl

oli (Oct 21 2018 at 21:16, on Zulip):

Jup, i figured it out. Stable hash equality implies hash equality... how did we manage to keep constants working at all you may ask... well, we didn't use any constants containing allocids inside query keys

mw (Oct 22 2018 at 09:00, on Zulip):

great that you figured it out!

Last update: Nov 20 2019 at 01:25UTC