Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Type checker awareness of partially-unknown collections #52

Merged
merged 2 commits into from
May 1, 2017
Merged

Type checker awareness of partially-unknown collections #52

merged 2 commits into from
May 1, 2017

Commits on May 1, 2017

  1. eval: check for unknowns in output before we begin concatenating 

    When the type checker finds unknowns it will generally skip any AST
rewriting it would normally do to insert type conversions, so if the
output result contains at least one unknown then it's possible that our
results would not all be of type string as we would usually expect.

To guard against this, we check first if there are any unknowns and just
return early, before we even start building our result buffer.
    @apparentlymart
    apparentlymart committed May 1, 2017
    Configuration menu
    Copy the full SHA
    4347190 View commit details
    Browse the repository at this point in the history

  2. Type checker awareness of partially-unknown collections 

    Earlier we made the evaluator support collections (lists and maps) that
have a mixture of known and unknown members. However, since the type
checker was not also aware of this it was short-circuiting as before
and skipping type checking of any expression dependent on a value from
a partially-unknown collection.

As well as missing some conversions, which was masked by the evaluator's
own short-circuiting as expected, this also caused us to skip the
conversion of arithmetic to built-in functions, which then caused the
evaluator to fail since it doesn't have any support for direct evaluation
of arithmetic.

This follows the same principle as the evalator changes: there's no longer
a global rule that any partially-unknown value gets flattened to a total
unknown when read from a variable, so each node type separately must deal
with the possibility of unknowns and decide what their behavior will be
in that case.

For most node types the behavior is simple: any unknowns mean that the
result is itself unknown. For index, we optimistically assume that
unknown values will become known values of the correct type on a future
pass and so we let them pass through, which is safe because of our
existing changes to how the evaluator supports unknowns.

This also includes a reorganization of the helper functions
VariableListElementTypesAreHomogenous and
VariableMapValueTypesAreHomogenous to make the different cases easier to
follow in the presence of unknowns.
    @apparentlymart
    apparentlymart committed May 1, 2017
    Configuration menu
    Copy the full SHA
    238ad9c View commit details
    Browse the repository at this point in the history