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
Elm: 0.19.1
Browser: N/A
Operating System: Linux
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
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
This SCCE crashes the compiler, but if a type signature is added to
problem
or the functioncrashIfFunctionStartsWithAtoS
is named with a name that starts with letters t,u,v,w,x,y or z then it instead correctly reports:Full Crash Output