More eager lsp check about nickel HOT 2 CLOSED

There are different ways to go about this, but note that in general checking a local contract might require values from the outer scope, or even values that aren't known at writing time (such as inputs of the configuration).

One way could be to try to evaluate the expression, and just ignore any error that isn't a contract error (such as missing field, or even just classify errors that should be reported immediately versus the ones that could stem from evaluating just a fragment of the program).

Another possibility, for simple cases, could be to try to infer a type for the subexpression, and compare that to basic contracts - if it fails to typecheck, we can't say anything, but if it succeeds with a type that is incompatible with the contract, then there is a problem. Both approaches (and there's probably more, such as just running the full program and reporting any error on command) have different trade-offs:

• Tthe partial evaluation one is simple and generic, and handle custom contracts, but can't handle unknown inputs (i.e won't report obviously wrong things such as { foo | Number, bar | String = foo ++ "a"})
• The typing approach can't handle custom contract, and can't handle ill-typed terms (that aren't necessarily wrong, just not accepted by the static typechecker), but better handles incomplete values.

Or maybe we can combine both?

from nickel.

I believe this is closed by the same PR as #1586, giving stuff like this in practice:

Feel free to re-open, or open new issues for more specific aspects of in-code contract evaluation.

from nickel.