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 when using typeof #42060

Closed
jFransham opened this issue May 17, 2017 · 6 comments
Closed

ICE when using typeof #42060

jFransham opened this issue May 17, 2017 · 6 comments
Labels
C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@jFransham
Copy link
Contributor

Obviously typeof isn't used in the current version of Rust, but if you do try to use it you get some strange behaviour. rustc correctly reports that typeof is unimplemented, and the error message is sensible if used with a constant expression, but using it with local variables causes an ICE.

Minimum code sample:

fn main() {
    let thing = ();
    let other: typeof(thing) = thing;
}

I'd expect this to return the same error as doing typeof(5), which is:

rustc 1.17.0 (56124baa9 2017-04-24)
error[E0516]: `typeof` is a reserved keyword but unimplemented
 --> <anon>:3:16
  |
3 |     let other: typeof(5) = thing;
  |                ^^^^^^^^^ reserved keyword

error: aborting due to previous error

But instead I get this:

rustc 1.17.0 (56124baa9 2017-04-24)
error[E0516]: `typeof` is a reserved keyword but unimplemented
 --> <anon>:3:16
  |
3 |     let other: typeof(thing) = thing;
  |                ^^^^^^^^^^^^^ reserved keyword

error: internal compiler error: /checkout/src/librustc_typeck/check/mod.rs:1527: no type for local variable local thing (id=8)
 --> <anon>:3:23
  |
3 |     let other: typeof(thing) = thing;
  |                       ^^^^^

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md#bug-reports

thread 'rustc' panicked at 'Box<Any>', /checkout/src/librustc_errors/lib.rs:377
note: Run with `RUST_BACKTRACE=1` for a backtrace.
@Mark-Simulacrum Mark-Simulacrum added the I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ label May 17, 2017
@eddyb
Copy link
Member

eddyb commented Jun 7, 2017

cc @nikomatsakis I think we'll have to make typeof work like closures if we want it to have access to variables in scope. Either that or we could ban this example in rustc_resolve.

@eddyb eddyb added I-nominated T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Jun 7, 2017
@nikomatsakis
Copy link
Contributor

@eddyb I don't quite know what you mean by "work like closures"? Work like closures in which respect?

@eddyb
Copy link
Member

eddyb commented Jun 7, 2017

In terms of sharing inference, which would fix this ICE.

@nikomatsakis
Copy link
Contributor

@eddyb I see. That seems ok. I thought you meant upvar inference or something.

@nikomatsakis
Copy link
Contributor

triage: P-medium

@rust-highfive rust-highfive added P-medium Medium priority and removed I-nominated labels Jun 8, 2017
@Mark-Simulacrum Mark-Simulacrum added the C-bug Category: This is a bug. label Jul 22, 2017
@vi
Copy link
Contributor

vi commented Sep 7, 2017

Another ICE case: fn f(){let q=1;<typeof(q)>::N}

wesleywiser added a commit to wesleywiser/rust that referenced this issue Jul 20, 2018
wesleywiser added a commit to wesleywiser/rust that referenced this issue Jul 20, 2018
@bors bors closed this as completed in 8c5ef0a Jul 26, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: This is a bug. I-ICE Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️ P-medium Medium priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

6 participants