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

Type checker panic on type alias with type variable #2489

Closed
rtfeldman opened this issue Feb 14, 2022 · 8 comments · Fixed by #2976
Closed

Type checker panic on type alias with type variable #2489

rtfeldman opened this issue Feb 14, 2022 · 8 comments · Fixed by #2976
Labels
bug Something isn't working P-high High priority/frequency type checking Relates to type checking compiler stage

Comments

@rtfeldman
Copy link
Contributor

As of 91483db this can be reproduced by adding the following to any .roc file and running roc check on it:

Foo a : [ Foo a ]

foo = \arg ->
    x : Foo *
    x = arg

    {}

It panics with:

Rigids [116]
Failing [116]
'assertion failed: {\n let failing: Vec<_> =\n rigid_vars.iter().filter(|&var|\n {\n !subs.redundant(*var) &&\n subs.get_rank(*var) != Rank::NONE\n }).collect();\n if !failing.is_empty() {\n println!(\"Rigids {:?}\", & rigid_vars);\n println!(\"Failing {:?}\", failing);\n }\n failing.is_empty()\n}',
compiler/solve/src/solve.rs:572:21

Things that make it no longer crash:

  • Removing the x : Foo * annotation
  • Removing the type variable from the Foo annotation
  • Removing the \arg -> lambda (so it's just foo = and then the x def)
  • Assigning x = to something other than arg

Variations that still reproduce the crash:

  • Foo a : List a
  • Foo a : { field : a }

So the relevant part here seems to be the type variable in the alias!

@rtfeldman rtfeldman added bug Something isn't working type checking Relates to type checking compiler stage P-high High priority/frequency labels Feb 14, 2022
@ayazhafiz
Copy link
Member

My guess is that this would work if you instead made the type annotation “Foo b” or “Foo _”. My guess is generalization of “*” is treated specially. This will be another fun (or “fun”) bug ;)

@caiquefigueiredo would you be interested in working through this one?

@rtfeldman
Copy link
Contributor Author

rtfeldman commented Feb 15, 2022

Just tried it and the panic still happens with both Foo _ and Foo b - the plot thickens! 😃

@ayazhafiz
Copy link
Member

noooo

@rtfeldman
Copy link
Contributor Author

Darth Vader saying nooooooooo

@caiquefigueiredo
Copy link

@ayazhafiz sure! I'm not sure I can go at it alone, but it seems fun :)

@ayazhafiz
Copy link
Member

This is one place where the original checker code did not diverge from Elm at all. For whatever reason Elm does not have a problem with this: https://ellie-app.com/hd3JrwdkSD3a1

But I think this is a bug in Elm. Looking further.

@ayazhafiz
Copy link
Member

I think this is fine and the panic should just be removed. Posted in Zulip: https://roc.zulipchat.com/#narrow/stream/231635-compiler-development/topic/Can.20rigids.20flow.20out.3F

@ayazhafiz
Copy link
Member

Elm has the same problem, but Elle doesn't show it. I'm not sure why. But I hit it in a local build of elm/compiler

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working P-high High priority/frequency type checking Relates to type checking compiler stage
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants