elm / compiler

Compiler for Elm, a functional language for reliable webapps.
https://elm-lang.org/
BSD 3-Clause "New" or "Revised" License
7.51k stars 656 forks source link

SSCCE to crash type inference using incorrect annotation #1525

Closed rtfeldman closed 6 years ago

rtfeldman commented 7 years ago

EDIT: revised to use the better example in https://github.com/elm-lang/elm-compiler/issues/1525#issuecomment-267857688

To Reproduce

  1. Put the code below in a file called Main.elm
  2. elm-make --yes Main.elm
type alias Whatever =
    ()

tooGeneral : a -> Int
tooGeneral a =
    alwaysOne a

alwaysOne : Whatever -> Int
alwaysOne _ =
    1
elm-make: It looks like something went wrong with the type inference algorithm.

Unable to generalize a type variable. It is not unranked.

Please create a minimal example that triggers this problem and report it to
<https://github.com/elm-lang/elm-compiler/issues>
elm-make: thread blocked indefinitely in an MVar operation
process-bot commented 7 years ago

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

rtfeldman commented 7 years ago

@evancz SSCCE'd an elusive MVar crash!

chaseries commented 7 years ago

Ran into what I believe is the same bug. Steps to reproducing the bug for the program below are identical to those of @rtfeldman.

type alias T1 =
  ()

f : t1 -> Int
f t1 =
    g t1

g : T1 -> Int
g t1 =
  1

Compiler output:

It looks like something went wrong with the type inference algorithm.

Unable to generalize a type variable. It is not unranked.

Please create a minimal example that triggers this problem and report it to
<https://github.com/elm-lang/elm-compiler/issues>
elm-make: thread blocked indefinitely in an MVar operation
deBhal commented 7 years ago

I just ran into this too, by accidentally using a lowercase model instead of a capital Model in a type signature.

You can get here by pasting the elm architecture forms example into http://elm-lang.org/try and changing that one character in the view type signature: view : Model -> Html Msg -> view : model -> Html Msg

It's pretty confusing when you're new to the language!

rtfeldman commented 7 years ago

Updating OP with a better example. Here's the original example, for posterity:

type Msg
    = Report (List String)

type Problem a =
    Problem a

-- This annotation is incorrect because it is too general. It should be:
-- foo : Result (Problem (List String)) Msg -> Msg
foo : Result (Problem a) Msg -> Msg
foo result =
    case result of
        Ok msg ->
            msg

        Err (Problem errors) ->
            Report errors

Compiler output:

It looks like something went wrong with the type inference algorithm.

Unable to generalize a type variable. It is not unranked.

Please create a minimal example that triggers this problem and report it to
<https://github.com/elm-lang/elm-compiler/issues>
elm-make: thread blocked indefinitely in an MVar operation

The List String in Report is crucial to reproducing the bug. Changing it to String yields the correct error message instead of crashing:

-- TYPE MISMATCH ------------------------------------------------------ Main.elm

The argument to function `Report` is causing a mismatch.

19|             Report errors
                       ^^^^^^
Function `Report` is expecting the argument to be:

    String

But it is:

    a

Hint: Your type annotation uses type variable `a` which means any type of value
can flow through. Your code is saying it CANNOT be anything though! Maybe change
your type annotation to be more specific? Maybe the code has a problem? More at:
<https://github.com/elm-lang/elm-compiler/blob/0.18.0/hints/type-annotations.md>

Compilation succeeds if the incorrect annotation is fixed (as described in a comment in the code) or if the offending annotation is removed.

skrytebane commented 6 years ago

I'm not sure this is the same issue, but this slightly stripped sample from Elm in Action by @rtfeldman also causes the same error if I omit the signature of onImmediateValueChange.

import Html.Events exposing (on)
import Json.Decode exposing (Decoder, at, int)

-- onImmediateValueChange : (Int -> msg) -> Html.Attribute msg
onImmediateValueChange toMsg =
    let
        targetImmediateValue = at [ "target", "immediateValue" ] int

        -- It doesn't crash if I omit this signature.
        msgDecoder : Decoder msg
        msgDecoder = Json.Decode.map toMsg targetImmediateValue
    in
        on "immediate-value-changed" msgDecoder
evancz commented 6 years ago

Based on commit 4b25980d93ada12236c794f35570e197be82f787, I am now seeing the following error in my development build!

screen shot 2018-03-06 at 1 32 54 pm

rtfeldman commented 6 years ago

Awesome! 😺

rtfeldman commented 6 years ago

Wow, that commit closed a lot of issues! 😮

evancz commented 6 years ago

Haha, yeah, I made the meta issue on the "unranked" thing because I figured it would be like this. A lot of type inference bugs are like two characters that indicate some deep misunderstanding 😄