Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recent regression in diagnostics: "overflow evaluating the trait core::kinds::Sized for the type <generic #139>" #18400

Closed
japaric opened this issue Oct 28, 2014 · 3 comments · Fixed by #19780
Labels
E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.

Comments

@japaric
Copy link
Member

japaric commented Oct 28, 2014

STR

trait Set<T> {
    fn contains(&self, T) -> bool;
    fn set(&mut self, T);
}

impl<'a, T, S> Set<&'a [T]> for S where
    T: Copy,
    S: Set<T>,
{
    fn contains(&self, bits: &[T]) -> bool {
        bits.iter().all(|&bit| self.contains(bit))
    }

    fn set(&mut self, bits: &[T]) {
        for &bit in bits.iter() {
            self.set(bit)
        }
    }
}

fn main() {
    let bits: &[_] = &[0, 1];

    0.contains(bits);
}

Output

overflow.rs:24:5: 24:21 error: overflow evaluating the trait `core::kinds::Sized` for the type `<generic #139>`
overflow.rs:24     0.contains(bits);
                   ^~~~~~~~~~~~~~~~
overflow.rs:24:5: 24:21 error: overflow evaluating the trait `core::kinds::Copy` for the type `<generic #139>`
overflow.rs:24     0.contains(bits);
                   ^~~~~~~~~~~~~~~~
overflow.rs:24:5: 24:21 error: overflow evaluating the trait `core::kinds::Sized` for the type `<generic integer #2>`
overflow.rs:24     0.contains(bits);
                   ^~~~~~~~~~~~~~~~
overflow.rs:24:5: 24:21 error: overflow evaluating the trait `Set<<generic #139>>` for the type `<generic integer #2>`
overflow.rs:24     0.contains(bits);
                   ^~~~~~~~~~~~~~~~
overflow.rs:24:16: 24:20 error: mismatched types: expected `&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[&[<generic #139>]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]]`, found `&[<generic integer #0>]` (expected &-ptr, found integral variable)
overflow.rs:24     0.contains(bits);
                              ^~~~
error: aborting due to 5 previous errors

Version

rustc 0.13.0-dev (9a778bc55 2014-10-28 10:11:51 +0000)

Compare it to the output of the playpen:

<anon>:24:5: 24:21 error: the trait `Set<<generic integer #0>>` is not implemented for the type `<generic integer #2>`
<anon>:24     0.contains(bits);
              ^~~~~~~~~~~~~~~~
error: aborting due to previous error
playpen: application terminated with error code 101
Program ended.

@thestinger Do you know what's the playpen current rustc version?

According to rusti, the version is/was:

NOTICE: rustc 0.13.0-dev (2130f2221 2014-10-21 19:32:10 +0000)

cc @nikomatsakis

EDIT Added playpen version

@nikomatsakis
Copy link
Contributor

Hmm, I'm not sure if there's a problem here. I mean, this is definitely a cyclic reasoning sort of situation. You're saying that "for any type S that implements Set for something copyable, I will implement it S for &[T] (which is also copyable)". And there are no other impls. So I can see why a cycle arises.

@japaric
Copy link
Member Author

japaric commented Oct 29, 2014

So I can see why a cycle arises.

Could you explain how the compiler ends in a cycle? I can sort of understand how the compiler ends up with the playpen version of the error message:

Facts

  • (S).contains(&[T]) method call
  • S and T are generic integers
  • impl Set<&[T]> for S where T: Copy, S: Set<T>

Processing

  • Search for impl that matches (self).contains(&[T])
  • Only found impl Set<&[T]> for S
  • Look at bounds:
    • T: Copy: OK
    • S: Set<T>: Bound not met
  • Raise error: "Set<T> is not implemented by S"

@nikomatsakis
Copy link
Contributor

@japaric what happens is that the compiler tries to determine if the impl applies to the type of the integral literal S. At that point it hasn't processed the arguments of the method call (we need to resolve the method before processing the arguments so we can provide type hints and so forth), and thus it actually only knows that the element type is some variable (let's call it $0).

It seems an impl that says "Set<&T> applies if S is a type that implements Set<T>", so it assumes that maybe $0=&$1 and goes off to look for an impl of Set<$1>. But this is just where we started, basically. (We were looking for an impl of `Set<$0>.) So we wind up repeating the same reasoning ad infinitum.

@emberian emberian added the regression-from-stable-to-nightly Performance or correctness regression from stable to nightly. label Nov 12, 2014
@ghost ghost added the E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. label Dec 12, 2014
bors added a commit that referenced this issue Dec 18, 2014
Closes #5988.
Closes #10176.
Closes #10456.
Closes #12744.
Closes #13264.
Closes #13324.
Closes #14182.
Closes #15381.
Closes #15444.
Closes #15480.
Closes #15756.
Closes #16822.
Closes #16966.
Closes #17351.
Closes #17503.
Closes #17545.
Closes #17771.
Closes #17816.
Closes #17897.
Closes #17905.
Closes #18188.
Closes #18232.
Closes #18345.
Closes #18389.
Closes #18400.
Closes #18502.
Closes #18611.
Closes #18783.
Closes #19009.
Closes #19081.
Closes #19098.
Closes #19127.
Closes #19135.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
E-needs-test Call for participation: An issue has been fixed and does not reproduce, but no test has been added. regression-from-stable-to-nightly Performance or correctness regression from stable to nightly.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants