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

ICE: Computing fictitious types #6319

Closed
alexcrichton opened this issue May 8, 2013 · 8 comments
Closed

ICE: Computing fictitious types #6319

alexcrichton opened this issue May 8, 2013 · 8 comments
Milestone

Comments

@alexcrichton
Copy link
Member

This program

fn error(m: uint, positions: ~[()]) { 
  match m {                           
    i => {                            
      let (a, b) = positions[i];      
    }                                 
  }                                   
}                                     

fn main() {}                          

generates:

$ rustc ./foo.rs
error: internal compiler error: Asked to compute contents of fictitious type

Additionally, a similar program

fn error(m: uint, positions: ~[()]) { 
  let (a, b) = positions[m];      
}                                     

fn main() {}                          

yields

$ rustc ./foo.rs
./foo.rs:4:11: 4:12 warning: unused variable: `a`
./foo.rs:4       let (a, b) = positions[m];
                      ^
./foo.rs:4:14: 4:15 warning: unused variable: `b`
./foo.rs:4       let (a, b) = positions[m];
                         ^
error: internal compiler error: adt::represent_type called on non-ADT type
@jbclements
Copy link
Contributor

+1, I'm running into this, too.

@jbclements
Copy link
Contributor

in my case, it turned out to be a missing ampersand on the pattern match for the tuple. I spent a bit of time digging around in the compiler to figure out whether it would be possible to at least attach some span info to the error message, but I came up empty.

@nikomatsakis
Copy link
Contributor

This seems like a missing error report to me. Clearly these programs should not be type checking, and those ICEs I believe come from passes that follow type checking. Perhaps an over-suppressed error?

@jbclements
Copy link
Contributor

nominating for Production Ready

@ssbr
Copy link

ssbr commented May 11, 2013

I found this error in a different context, and another ICE in a related context (both for code that shouldn't pass the type checker):

<ssbr> rusti: match Some((1u, 'a')) { (x, _) => 1u, _ => 2u }
<rusti> error: internal compiler error: Asked to compute contents of fictitious type
<ssbr> rusti: match Some((1u, 'a')) { (_, _) => 1u, _ => 2u }
<rusti> error: internal compiler error: adt::represent_type called on non-ADT type

@ghost ghost assigned catamorphism May 11, 2013
@catamorphism
Copy link
Contributor

I've fixed this in a branch. Just testing now.

catamorphism added a commit to catamorphism/rust that referenced this issue May 12, 2013
In rust-lang#6319, several people mentioned they ran into a "computing
fictitious type" ICE in trans. This turns out to be because some
of my recent changes to typeck::check::_match resulted in type errors
getting reported with ty_err as the expected type, which meant the errors
were suppressed, and typechecking incorrectly succeeded (since the errors
weren't recorded).

Changed the error messages in these cases not to use an expected type at all,
rather, printing out a string describing the type that was expected (which is
what the code originally did). The result is a bit repetitive and the
proliferation of error-reporting functions in typeck::infer is a bit annoying,
but I thought it was important to fix this now; more cleanup can happen later.
@catamorphism
Copy link
Contributor

Fixed pending #6427

bors added a commit that referenced this issue May 12, 2013
r? @nikomatsakis In #6319, several people mentioned they ran into a "computing
fictitious type" ICE in trans. This turns out to be because some
of my recent changes to typeck::check::_match resulted in type errors
getting reported with ty_err as the expected type, which meant the errors
were suppressed, and typechecking incorrectly succeeded (since the errors
weren't recorded).

Changed the error messages in these cases not to use an expected type at all,
rather, printing out a string describing the type that was expected (which is
what the code originally did). The result is a bit repetitive and the
proliferation of error-reporting functions in typeck::infer is a bit annoying,
but I thought it was important to fix this now; more cleanup can happen later.
@catamorphism
Copy link
Contributor

Fixed in 638b394

flip1995 pushed a commit to flip1995/rust that referenced this issue Nov 20, 2020
Rustup

changelog: none

r? `@ghost`
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants