Stream: t-compiler

Topic: weird-query-stacktrace


oli (Oct 19 2018 at 09:09, on Zulip):

I have just seen that the following query backtrace (or variants of it) are super common:

oli (Oct 19 2018 at 09:09, on Zulip):

(deleted)

oli (Oct 19 2018 at 09:09, on Zulip):
#0 [const_eval] const-evaluating `<std::collections::VecDeque<A> as std::cmp::PartialEq<&'b mut [B; _]>>::{{constant}}`
#1 [evaluate_obligation] evaluating trait selection obligation `_: std::cmp::PartialEq<_>`
#2 [typeck_tables_of] processing `X`
#3 [mir_built] processing `X`
#4 [unsafety_check_result] processing `X`
#5 [mir_const] processing `X`
#6 [mir_const_qualif] processing `X`
  --> /home/oliver/Projects/rust/rust/src/test/ui/consts/const-integer-bool-ops.rs:18:18
   |
LL | const ARR: [i32; X] = [99; 34];
   |                  ^
#7 [mir_const_qualif] processing `ARR::{{constant}}`
#8 [const_eval] const-evaluating `ARR::{{constant}}`
#9 [check_item_well_formed] processing `ARR`
oli (Oct 19 2018 at 09:09, on Zulip):

(deleted)

oli (Oct 19 2018 at 09:10, on Zulip):

So for evaluating an array length, we are out of some reason computing obligations about array equality

oli (Oct 19 2018 at 09:11, on Zulip):

I just feel like that is wrong, considering X is defined as const X: usize = 42 && 39;

oli (Oct 19 2018 at 09:12, on Zulip):

(yes that is an error, it's from a ui test)

nikomatsakis (Oct 19 2018 at 10:08, on Zulip):

are you referring to the #0 entry?

nikomatsakis (Oct 19 2018 at 10:09, on Zulip):

sounds like the problem is that the trait obligation is "underconstrained" and the trait solver goes crazy looking at impls...

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

hm. ok, I'll try to reproduce with successfully compiling code, makes sense that erroneous code might do weird things

Last update: Nov 20 2019 at 01:10UTC