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

Compiler crash (thread blocked indefinitely in an MVar operation) instead of type error #2206

Open jmbromley opened 3 years ago

jmbromley commented 3 years ago

Quick Summary:

Under certain circumstances the compiler crashes with thread blocked indefinitely in an MVar operation instead of producing a type error. This seems to be involved in type inference as the crash disappears with the addition of a type signature, but the exact circumstances are very 'fragile' and can even depend on the name that is given to a function! See the SSCCE below.

SSCCE


module Main exposing (problem)

type alias Item =
    { one : ()
    , two : ()
    }

type Custom a b
    = First a
    | Second b

expectItem : Item -> ()
expectItem =
    always ()

{- Crash goes away if a type signature is added to problem:

   problem : Item -> () -> ()

   or if the second definition within the let-block has a name that starts with t-z
-}

problem item room =
    let
        showItemHasDotOne =
            item.one

        crashIfFunctionNameStartsWithAtoS =
            expectItem
                { item | two = Second room }
    in
    ()

This SCCE crashes the compiler, but if a type signature is added to problem or the function crashIfFunctionStartsWithAtoS is named with a name that starts with letters t,u,v,w,x,y or z then it instead correctly reports:

The 1st argument to `expectItem` is not what I expect:

35|             expectItem
36|                 { item | two = Second room }
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
This argument is a record of type:

    { one : (), two : Custom a b }

But `expectItem` needs the 1st argument to be:

    Item

Full Crash Output

Compiling ...elm: ./Data/Vector/Generic/Mutable.hs:709 (modify): index out of bounds (3,3)
CallStack (from HasCallStack):
  error, called at ./Data/Vector/Internal/Check.hs:87:5 in vector-0.12.1.2-42dUnWF6CAtEM7Ve6w70hw:Data.Vector.Internal.Check

-- ERROR -----------------------------------------------------------------------

I ran into something that bypassed the normal error reporting process! I
extracted whatever information I could from the internal error:

>   thread blocked indefinitely in an MVar operation

These errors are usually pretty confusing, so start by asking around on one of
forums listed at https://elm-lang.org/community to see if anyone can get you
unstuck quickly.

-- REQUEST ---------------------------------------------------------------------

If you are feeling up to it, please try to get your code down to the smallest
version that still triggers this message. Ideally in a single Main.elm and
elm.json file.

From there open a NEW issue at https://github.com/elm/compiler/issues with your
reduced example pasted in directly. (Not a link to a repo or gist!) Do not worry
about if someone else saw something similar. More examples is better!

This kind of error is usually tied up in larger architectural choices that are
hard to change, so even when we have a couple good examples, it can take some
time to resolve in a solid way.elm: thread blocked indefinitely in an MVar operation
github-actions[bot] commented 3 years ago

Thanks for reporting this! To set expectations:

Finally, please be patient with the core team. They are trying their best with limited resources.