Panic: "internal compiler error: ident only path should have been covered already"

[insaneinside]

This error is triggered by providing type parameters to a generic type in a match pattern.

e.g.

#![crate_type = "staticlib"]

pub struct Foo<T>(T, T);

impl<T> Foo<T> {
    fn foo(&self) {
        match *self {
            Foo<T>(x, y) => println!("Goodbye, World!")
        }
    }
}

Playpen here.

[ghost]

This is not the only way to make it panic.

http://is.gd/LcO1Pw
Using nightly.

rustc 1.0.0-nightly (b63cee4 2015-02-14 17:01:11 +0000)
binary: rustc
commit-hash: b63cee4
commit-date: 2015-02-14 17:01:11 +0000
host: x86_64-unknown-linux-gnu
release: 1.0.0-nightly

[ghost]

I also have this problem when pattern matching types with <>.

[Kimundi]

It seems I introduced this bug with #22158, sorry 😦.

The ICE happens because I had refactored parts of the parser that seemed to be dead code, apparently I was wrong about that though, and neither testsuite nor the rest of the compiler codebase walked into it.

The good news is that its straightforward to fix, someone just needs to revert the linked part of the diff (And add a test for it...).

[bombless]

Seems that I made a different approach.. did I do something wrong? :P

[Kimundi]

Was it legal before to have type paramters there, or did it lead to an error in a later stage?

[bombless]

It was legal, see my comment here #22546 (comment)

[bombless]

I made a patch for this, changed LifetimeAndTypesWithColons to LifetimeAndTypesWithColons(bool) to disable type parameters in path in some condition to reject type parameters in pattern, and it is easy.

[Kimundi]

Okay, so allowing Foo<T> is wrong, because Foo::<T> should be accepted?

[bombless]

Foo::<T> make sense to me, and I'd admit we don't really need it in pattern.
But there's another thing a little bit related and I think we can do some effort for it: #22644

[Kimundi]

Well, thats an unrelated issue to this one.

Looking at your patch, it might be possible to catch the Foo<T> case by removing the token::Lt in the earlier can_be_enum_or_struct initialization, since IDENT < is apparently not legal in a pattern: No comparison operators, and generics are parsed as Foo::<T> already.

[bombless]

😄 Yeah I have the same feeling.
But we can also catch the error just before anything go wrong, it may even save some CPU cycles on early error handling (partly joking).

[Kimundi]

Right, detecting the misplaced < and giving a proper error message that guides one to use the Foo::<T> form would be the best.

[bombless]

Right, detecting the misplaced < and giving a proper error message that guides one to use the Foo::<T> form would be the best.

Agreed.
Do you think we may wait for a > for that error message?
I think it would be great if we can directly point out Foo<T> should be Foo::<T>.
As it is a status we are doing error handling, we cannot make mess that much.
And if we meet something that don't even look like a path, then we just stop reading tokens and point out token < is unexpected.

This kind of code may be hard to maintain, though.