To facilitate experimentation, I've left the old code in place, but
disabled it using a const bool `fullTopLevelInference`. The old code
can be re-enabled by setting this bool to `false`. Once we are sure
that we want to proceed with this approach, we can remove the old
code.
I believe that with this change, all expressions that can be type
inferred inside a method body can now be type inferred at top level,
provided that there are no circular dependencies.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2942153002 .
This CL lifts all of the restrictions on top level type inference
except for one: the restriction that expressions used for top level
type inference cannot depend on the types of instance getters,
instance setters, or instance fields. (That restriction will be
lifted in a later CL).
The technique is: to determine the dependencies of an expression,
rather than recurse through the expression applying the rules for what
constitutes an "immediately evident" expression, we simply do a dry
run of the inference algorithm and record what static fields were
accessed. To avoid recording bogus dependencies on fields whose type
doesn't matter, this dry run skips subexpressions whose type isn't
needed.
To facilitate experimentation, I've left the old code in place, but
disabled it using a const bool `extendedTopLevelInference`. The old
code can be re-enabled by setting this bool to `false`. Once we are
sure that we want to proceed with this approach, we can remove the old
code.
Note that this makes the behavior begin to diverge with analyzer
behavior, so I've created a new test directory:
pkg/front_end/testcases/inference_new/, to hold test cases which
aren't expected to match analyzer. Analyzer is only tested against
the test cases in pkg/front_end/testcases/inference/.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2935323002 .
Multiple changes were required:
- The analyzer's mock SDK had an incorrect return type for
`num.operator/`.
- We weren't considering the RHS of the binary operators `+`, `-`,
`*`, and `%` to be an inference dependency (we need to, since the
special overload rules for int depend on the type of the RHS).
- We weren't executing the overload logic when doing top level type
inference.
- The logic for deciding what operators are overloaded was incorrect.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2940703002 .
The approach from the las CL (try to figure out the structure of the
assignment expression from the desugared result) turned out to be
unsustainably complex. In this version we keep track of the structure
while doing the desugaring, and then store the result in a wrapper
object the kernel AST. The wrapper object defers visit methods to the
object it wraps, so when the kernel objects are serialized to disk,
the wrapper disappears.
I also took the liberty of removing the code that inserts types
into the temporary variables and conditional expressions
introduced by desugaring. I will add this in a later CL if it
proves to be necessary.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2927013004 .
This code was part of an attempt to prototype some possible extensions
to type promotion to handle `if (x is! Foo)`. I thought I had
rendered it harmless, but it was having some buggy effects.
Also added a test case demonstrating the problem.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2914093002 .
The code is correct as is (at least insofar as it matches analyzer's
behavior). I've added a new test to verify this, and I've made a
comment on the spec asking for it to be updated to match analyzer's
behavior.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2916633002 .
When inferring the type of an invocation for top level inference, if
type parameters are not specified, then it is an error. So we should
not recurse into subexpressions (even if inferenceNeeded is `true`).
This avoids confusion by making it clear to the user that we don't
take subexpressions into account when doing top level type inference,
even when recovering from type inference errors.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2911323002 .
This required implementing FutureOr rules in
type_constraint_gatherer.dart. It also required fixing an incorrect
type in analyzer's mock SDK, which had some follow on effects on
analyzer unit tests.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2904263003 .
Paul Berry