Strange compiler error - cannot find a field that is obviously there.

[Rupert Smith]

When I try to compile this:

module Model exposing (..)

type Account
    = Account
        { uuid : String
        , username : Maybe String
        , password : Maybe String
        , root : Maybe Bool
        , id : Maybe String
        }




accountEncoder : Account -> Encode.Value
accountEncoder (Account model) =
    [ Just ( "uuid", Encode.string model.uuid )
    , Maybe.map (\username -> ( "username", Encode.string username )) model.username
    , Maybe.map (\password -> ( "password", Encode.string password )) model.password
    , Maybe.map (\root -> ( "root", Encode.bool root )) model.root
    , Maybe.map (\id -> ( "id", Encode.string id )) model.id
    ]
        |> catMaybes
        |> Encode.object

The compiler is somehow blind to the 'uuid' field being there:

-- TYPE MISMATCH --------------------------------- src/auth-client/elm/Model.elm


`model` does not have a field named `uuid`.


176|     [ Just ( "uuid", Encode.string model.uuid )
                                        ^^^^^^^^^^
The type of `model` is:


    { id : Maybe String
    , password : Maybe String
    , roles : Maybe (List Role)
    , root : Maybe Bool
    , salt : Maybe String
    , username : Maybe String
    }




Which does not contain a field named `uuid`.

Erm.. what?

Interestingly, if I clear out 'elm-stuff' and try again, it fails but with different errors relating to other modules, some of which depend on this one. I don't get this error, but I do get an error in the Account.Service module which depends on this Model module saying that some of its code tries to create Accounts without uuids.

I just added the 'uuid' field, and the modules that consume this one do not yet have it in their code. My hypothesis is that the later modules are compiling some of the way, some information from that is being written to disk, and on the next compilation run that information is found to conflict with the Account type and the compiler comes out with this confusing error message. I see .elmi and .elmi files under 'elm-stuff' for the Account.Service module which depends on this one.

Perhaps if the compiler fails to compile a module it should do so more atomically, and not output a .elmi and .elmo files?

Also, getting different errors on two consecutive compiler runs is not idempotent behaviour.

Has anyone seen an error like this before? I don't see it in the github elm-compiler issues, so I though I might try and put together an SSCCE for it. Which I may manage to do, if my hypothese

[Rupert Smith]

On Friday, September 8, 2017 at 9:35:14 AM UTC+1, Rupert Smith wrote:

Has anyone seen an error like this before? I don't see it in the github elm-compiler issues, so I though I might try and put together an SSCCE for it. Which I may manage to do, if my hypothese

Which I may manage to do, if my hypothesis is correct. 

[Rupert Smith]

Bugger. 

I fixed the code so that the Account model has the uuid field, and the module which depends on that also now has the uuid field. A clean compiler run with elm-stuff deleted says that the dependant module has an extra 'uuid' field in it, not in the model, and a subsequent compiler run gives the original error message. The field is there and my code looks correct, yet the compiler won't run it.

If I try to pull out just an isolated example to make an SSCCE out of... the problem goes away.

[Rupert Smith]

On Friday, September 8, 2017 at 10:47:04 AM UTC+1, Rupert Smith wrote:

I fixed the code so that the Account model has the uuid field, and the module which depends on that also now has the uuid field. A clean compiler run with elm-stuff deleted says that the dependant module has an extra 'uuid' field in it, not in the model, and a subsequent compiler run gives the original error message. The field is there and my code looks correct, yet the compiler won't run it.

I wonder if it could be to do with my module being called 'Model', but there is also a Model type defined in the same scope. I have seen some strange compiler errors caused by a module/type name clash before. So I will try renaming the module or importing it under a different name. 

[Eelco Hoekema]

That absolutely looks like you still some old compiled stuff lying around somewhere. What happens if you copy the code to a clean directory, run elm-package install again?

Other possible reasons for weird errors: did you recently upgrade elm?

eelco

[Rupert Smith]

On Friday, September 8, 2017 at 7:52:34 PM UTC+1, Eelco Hoekema wrote:

That absolutely looks like you still some old compiled stuff lying around somewhere. What happens if you copy the code to a clean directory, run elm-package install again?

I have been deleting 'elm-stuff', is there more I need to delete to clean things up?

 

Other possible reasons for weird errors: did you recently upgrade elm?

No. 

[Vlad GURDIGA]

Hey Rupert! 👋

If I try to pull out just an isolated example to make an SSCCE out of... the problem goes away.

Hm… this is interesting! 🤔

I’m wondering what are other factors that could lead to that issue, which you have in the production context but not in SSCCE?

I haven’t seen mentioned your environment: Elm version? Operating System? The IDE or text editor? Could you please enumerate those? 🤓

[Ian Mackenzie]

Have you added type annotations to all top-level functions/values? My first guess would be some sort of type inference issue that's propagating across files, which can usually be narrowed down by explicitly annotating top-level stuff so that any discrepancies are caught as soon as possible.

[Rupert Smith]

On Monday, September 11, 2017 at 6:39:32 PM UTC+1, Ian Mackenzie wrote:

Have you added type annotations to all top-level functions/values? My first guess would be some sort of type inference issue that's propagating across files, which can usually be narrowed down by explicitly annotating top-level stuff so that any discrepancies are caught as soon as possible.

Yes, there are type annotations there. It is a good point though - I'll have a careful check through that I didn't miss any.