Undue ill-formed type error when using a record field as a type

[yannham]

Describe the bug
When using a record access like record.Contract as a type annotation, one get an enigmatic ill-formed type error.

To Reproduce

nickel> let foo = {Bar = Dyn}
nickel> (null | foo.Bar) : foo.Bar
error: ill-formed type
  ┌─ :1:1
  │
1 │ <unevaluated>
  │ ------------- ill-formed type

This fires whatever is on the RHS of the contract annotation null | _, as long as it is a custom contract., but requires a record access in the outer type annotation. For example, (null | Baz) : foo.Bar also triggers the error, but neither (null | Bar) : Baz nor (null | Dyn) : foo.Bar does.

Expected behavior
I expect the example program to be accepted and to return null.

Additional context
ill-formed type exception are almost always internal errors: they indicate that a non-row type ended up somewhere in a row position, but I believe those kind of types are impossible to write in the source syntax. There must be a mishandling of custom contracts used as a type somewhere, but it's surprising that anything depends on the structure of the custom contracts, which shouldn't ever be inspected by the typechecker...

[yannham]

After a bit more investigation, the typechecker doesn't like when flat type (contracts) are not variables, which is of course really limiting. Not throwing this error anymore is easy to solve; however the larger issue at hand is that this code appears in unify, where the typechecker has to decide if two flat types unify. And this is not a trivial matter. I'll open a separate issue for that.

[yannham]

(Separate issue: #724)

[yannham]

Closed by quickfix in #769. Keeping #724 open for a better long term solution.