Compiler: Definition order problem with unboxed types in --optimize

[Carlsson87]

The following SSCCE works fine when compiled without the --optimize flag, but causes a runtime exception when compiled with the --optimize flag.

module Main exposing (main)

import Browser
import Browser.Dom
import Html
import Task


main : Program () () ()
main =
    Browser.element
        { init = \_ -> ( (), Task.attempt (always ()) (Browser.Dom.focus "an-id") )
        , view = \_ -> Html.text ""
        , update = \_ _ -> ( (), Cmd.none )
        , subscriptions = \_ -> Sub.none
        }

• Elm 0.19
• Google Chrome 70.0.3538.77
• macOS Mojave 10.14

The problematic line in the compiled output is:

var elm$browser$Browser$Dom$NotFound = elm$core$Basics$identity;

which appears above/before the definition of elm$core$Basics$identity, which causes elm$browser$Browser$Dom$NotFound to be undefined.

[Checksum]

Just ran into this as well, but with elm$browser$Browser$Dom$NotFound. Can this be safely ignored till it's fixed, or should I be turning off --optimize?

[cedricss]

I just run into the same error with elm 0.19 and the --optimize flag:

Here is my minimal test case with a Browser.application and Browser.Dom.getElement, similar to the one posted above:

module Main exposing (main)

import Browser
import Browser.Dom
import Browser.Navigation as Nav
import Html exposing (Html)
import Task exposing (attempt)
import Url exposing (Url)


type alias Flags =
    {}


type Msg
    = NoOp


main : Program Flags () Msg
main =
    Browser.application
        { init = init
        , onUrlRequest = \_ -> NoOp
        , onUrlChange = \_ -> NoOp
        , view = \_ -> { title = "", body = [] }
        , update = \_ _ -> ( (), Cmd.none )
        , subscriptions = \_ -> Sub.none
        }


init : Flags -> Url -> Nav.Key -> ( (), Cmd Msg )
init flags url key =
    ( ()
    , Browser.Dom.getElement "id"
        |> Task.attempt (always NoOp)
    )

Related issue: https://github.com/elm/browser/issues/63

[evancz]

There is a fix for this, but just to set time expectations, there is quite a bit of work left before a 0.19.1 release is possible. In particular, I found some performance issues caused by laziness that require some larger changes to address reliably. Anyway, thank you for the report!