Projects intermittently say they compile successfully, when they are actually broken.

[krisajenkins]

Intermittently, I run elm make, and it says everything compiles successfully, but the app fails at runtime with various errors related to a function missing or a type definition being incorrect. Recompiling doesn't fix it (because it thinks there's no work to do). But deleting elm-stuff/build-artifacts and recompiling reveals a compiler error/warning. Running touch src/**/*.elm and recompiling also surfaces the missing error message.

The exact symptoms and circumstances change, but the problem boils down to, elm make thinks the project is completely and correctly compiled, but it's wrong. Forcing it to recompile completely spots an error.

Quite a few people have seen this issue now, and it's getting so "delete elm-stuff/build-artifacts," is become go-to advice. :-(

Below is my best effort at a SSCCE. It creates two small files, one of which depends on the other. Then it compiles them successfully. Next it changes them in a way that should break the project and recompiles. It ought to give this error:

-- TYPE MISMATCH ------------------------------------------------------- Bar.elm

The type annotation for `bar` does not match its definition.

6| bar : Foo
         ^^^
The type annotation is saying:

    String

But I am inferring that the definition has this type:

    number

Detected errors in 1 module.  

...but I just ran it 10 times in a row and in 9 of those it said everything had recompiled fine. Only one run correctly reported the error.

The script is here: https://gist.github.com/krisajenkins/8b2de1d221f2c26a55b6fa1a02dfc74d

It definitely reveals there's a problem with the dependency-tree calculation. Hopefully it's the same one that's been causing problems in the large.

Notes: The first time you run it it'll download the core libs, so expect the first run to take a minute. I'm asking you to run a shell script here, so do read it over first. You'll see it just creates two files Foo.elm and Bar.elm and runs elm-make. It's harmless, but don't blindly take my word for it.)

[process-bot]

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.

[krisajenkins]

Thank you process-bot. Here's what I missed out:

Elm: 0.17.1. OS: OSX 10.11.5. Browser: N/A.

[gdotdesign]

I can reproduce this issue consistently (or a possibly related one but have the same effect), I created a repository for it: https://github.com/gdotdesign/elm-make-bug

[note89]

Cannot reproduce this one but gdotdesigns one i can.

Elm: 0.17.1 OS: Ubuntu 16.10 Browser: N/A

[Zinggi]

I can reproduce the bug from gdotdesign's repository

Elm: 0.17.1 OS: Ubuntu 16.10 Browser: N/A

[manuscrypt]

So can I.

Elm: 0.17.1 OS: Windows 10

Only Platform-Installer used, no npm

On Sun, Jul 10, 2016 at 6:12 PM, Florian Zinggeler <notifications@github.com

wrote:

I can reproduce the bug from gdotdesign's repository https://github.com/gdotdesign/elm-make-bug

Elm: 0.17.1 OS: Ubuntu 16.10 Browser: N/A

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/elm-lang/elm-make/issues/107#issuecomment-231596860, or mute the thread https://github.com/notifications/unsubscribe/ASasR2FVPE1RZ-AejwC2wHAZ2GNrxlpnks5qURn7gaJpZM4JI1qR .

[note89]

This script reproduces the issue every time on my platform Ubuntu 16.10 Elm 17.1

#!/bin/bash

while true; do
        rm -rf elm-make-bug
        git clone git@github.com:gdotdesign/elm-make-bug.git > /dev/null 2>&1
        cd elm-make-bug
        elm-make Test.elm --yes  > /dev/null 2>&1
        perl -pi -e 's/A/B/g' Lib.elm
        elm-make Test.elm --yes  > /dev/null 2>&1
        perl -pi -e 's/Lib.A/Lib.B/g' Bar.elm
        elm-make Test.elm > /dev/null 2>&1
        echo $?
done

It should give a 1 for error but gives 0 for okey

if you remove the first elm-make it prints 1 everytime instead

[manuscrypt]

Following suit, this is the same script working for windows:

:loop @echo off rm -rf elm-make-bug git clone git@github.com:gdotdesign/elm-make-bug.git > /dev/null 2>&1 cd elm-make-bug elm-make Test.elm --yes > /dev/null 2>&1 perl -pi -e 's/A/B/g' Lib.elm elm-make Test.elm --yes > /dev/null 2>&1 perl -pi -e 's/Lib.A/Lib.B/g' Bar.elm elm-make Test.elm > /dev/null 2>&1 echo %errorlevel% cd .. goto loop

This return 0 every time with

Elm 0.17.1 on Windows 10 Enterprise, Version 1511, 10586.420

On Sun, Jul 10, 2016 at 9:19 PM, Nils Eriksson notifications@github.com wrote:

This script reproduces the issue every time on my platform Ubuntu 16.10 Elm 17.1

!/bin/bash

while true; do rm -rf elm-make-bug git clone git@github.com:gdotdesign/elm-make-bug.git > /dev/null 2>&1 cd elm-make-bug elm-make Test.elm --yes > /dev/null 2>&1 perl -pi -e 's/A/B/g' Lib.elm elm-make Test.elm --yes > /dev/null 2>&1 perl -pi -e 's/Lib.A/Lib.B/g' Bar.elm elm-make Test.elm > /dev/null 2>&1 echo $? done

It should give a 1 for error but gives 0 for okey

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/elm-lang/elm-make/issues/107#issuecomment-231605845, or mute the thread https://github.com/notifications/unsubscribe/ASasRy6d5E10H1oyBy-qvor3A-C18M-6ks5qUUXJgaJpZM4JI1qR .

[note89]

Most of the time i don't get runtime exceptions but i get error that i know are not correct like this one.

$ ./elm-make 
-- TYPE MISMATCH ------------------------------------------- ./src/App/State.elm

The type annotation for `initialModel` does not match its definition.

66| initialModel : String -> Model
                   ^^^^^^^^^^^^^^^
The type annotation is saying:

    String -> { ..., notification : () }

But I am inferring that the definition has this type:

    String -> { ..., notification : String }

i changed the model from () to String (don't ask me why.)

But still App.elm thinks that Notification.State.elm Has the old type. I also had and error in App.elm where i called initalData instead of initalModel after fixing that issue this inconsistency occurred

i went from

-- Notification.Types
type alias Model = ()
-- Notification.State
initialModel = ()

-- Notification.Types
type alias Model =
    String
-- Notification.State
initialModel =
    "Placeholder"

Removeing build-artifacts fixed the issue

[evancz]

@krisajenkins, are you calling elm-make on the root file every time, or are you calling it on various files in various orders?

[evancz]

Also, once we have an answer to that, we should take @process-bot's advice for long issues: summarize the important things in a new (better) issue.

[krisajenkins]

@evancz In the case of that script I first posted, the same file every time.

But more generally...I'm not 100% sure. I do do both. I can't say I've noticed any pattern where one works but the other fails...

[evancz]

I know you can mess things up by not using the root file. The decision whether to recompile is based on timestamps of files, so you can find yourself in situations where new files do not look new. Things messing up from the root is new to me though.

I guess using a timestamp is not robust enough. Do people know how this is handled in other compilers? I'd assume keeping track of it in a file you maintain yourself?

[krisajenkins]

FWIW, I'm fairly sure I only started seeing this when 0.17 was alpha'd.

(It's tough to be certain, because it was a while before I was convinced it was an Elm issue. But this issue has been around for weeks-to-a-month-or-two.)

[JustinLove]

I've seen this twice, both times immediately after elm package install Initially the error was that openFile failed for a new library .elmo, but when I attempted to rewind to a working state, changes were not impacting the output. Changing the exported or imported module names would cause a compile error, but mere string changes and introducing undefined symbols were not having any effect. Both times there was a minor version change in elm-core triggered by the install; the first time i thought that 0.17.1 update was required to match it, which I now think had the side effect of clearing the build artifacts.

In the most recent instance, I had file watchers running, recompiling two different root files and build targets with some shared files, such that elm-make was getting called with two roots, and both tended to run at or near the same time. Switching back to manual had no effect.

Elm: 0.17.0, 0.17.1. OS: OSX 10.11.5, 10.11.6

[evancz]

The fix in https://github.com/elm-lang/elm-make/commit/46ec85c0e8dc5f3427bde6e4f212b4f367ecbd07 is consistently fixing @gdotdesign's example program. I'm not sure about the example given by @krisajenkins.

I think it makes the most sense to release this with 0.18. There will be a review period before that release so we'll have time to do a bunch of testing, and I think this change would benefit from that kind of scrutiny.