Parser does not detect field initialization in a constructor despite exhaustive match clauses

[stefandd]

primitive Foo
    fun apply() : (U32 | None) => 1

type Bar is (U32 | None)

actor Main
    let bar : Bar

    new create(env : Env) =>
        match Foo()
        | let result : U32 =>
            bar = result
        | None =>
            bar = 0
        end

The field bar should have been successfully initialized in create() but the compiler complains about a '7:5: field left undefined in constructor' error

[SeanTAllen]

We discussed this during sync and @jemc thinks this isn't a huge amount of work but also that it isn't trivial. His fear is that exhaustive match checking happens after the initialization check (which would make this somewhat difficult).

[SeanTAllen]

"field left undefined in constructor" is currently done in the refer pass in refer_new.

exhaustive match is checked in is_match_exhaustive in the expression pass.

So we have a problem of ordering. If the exhaustive-ness match happened first this should be fine.

[SeanTAllen]

The specific check that fails in refer_new is (status != SYM_DEFINED)).

[SeanTAllen]

@jemc I feel like the correct thing do here is:

• move refer_new checks to verify pass.
• let the exhaustiveness work in expression pass set up the ast correctly for exhaustiveness (no else with no definition)
• run the equiv of refer_match again after exhaustiveness to consolidate branches

if the last is done i think that should define the symbol, but I could be wrong.

Can you verify?

[jemc]

If you do so, I suggest putting the checks in a new pass by themselves, since if it works like the refer pass currently does, it will be a pretty extensive pass touching a lot of different areas, so I think it's better to keep it in a separate pass, away from the relatively small and isolated checks currently in the verify pass.

In the Savi compiler I wrote a pass named completeness which serves this purpose (although that one works a bit differently than the one in ponyc does)

The main downside of moving this stuff out of the refer pass is that much of the code in the refer pass would likely need to be duplicated. Although maybe you can find a nifty way to reuse the symbol status tracking code instead of copying it.