This code is no longer needed because we no longer run the front end
in "kompile" mode.
Also remove the old expectations files used by the "kompile" tests.
I will remove more code in future CLs.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2980883003 .
This CL creates synthetic kernel objects for two additional
BodyBuilder corner cases:
- The synthetic "throw" expression created when code attempts to
construct an abstract class.
- The "throw" expression created when code attempts to assign to a
read-only expression.
With this change, we now create a KernelComplexAssignment object for
all assignments; this has allowed me to streamline the code for
creating assignments slightly.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2972873002 .
Note that no actual type inference needs to be performed, but we still
need to implement the _inferStatement() methods so that we can get rid
of the hack in KernelTypeInferrer.inferStatement. Also, we need to
call into the listener so that once this logic is hooked into
AstBuilder, analyzer will stay in sync with type inference.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2962583002 .
I implemented the correct logic for both SuperPropertyGet and
DirectPropertyGet, since there are TODO comments in the code
indicating that the former will be replaced by the latter when
possible.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2959823002 .
I implemented the correct logic for both SuperMethodInvocation and
DirectMethodInvocation, since there are TODO comments in the code
indicating that the former will be replaced by the latter when
possible.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2954403002 .
Note that since the first argument of an assert statement may be
either of type `bool` or `() -> bool`, and the second argument may be
any object, no type context is passed down in downward inference; the
only inference we need to do is to recursively invoke
`inferExpression` to ensure that subexpressions are inferred properly.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2959763002 .
These two tests were added some time ago, but they became corrupted
(presumably due to a formatter bug that has since been fixed). Later,
I moved the corrupted tests into the inference_new folder because they
didn't infer correctly with analyzer.
This CL re-introduces the original uncorrupted tests so that we don't
lose test coverage.
Note that these tests make use of a syntax that Fasta doesn't support
yet, so they are marked as failing.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2958623002 .
This CL makes two fixes:
1. When a field is visited for the second time (to infer
subexpressions), don't use the inferred field type as the context;
this can change the inference results in a few rare circumstances,
making it different from what would be inferred inside a method body.
2. When doing extended top level type inference is enabled, only skip
subexpressions whose type is not needed.
Note that some tests had to be moved (either partially or completely)
into pkg/front_end/testcases/inference_new to reflect the fact that
front_end type inference now produces more correct results than
analyzer. Also, the annotation comments in
pkg/front_end/testcases/inference_new/dependency_only_if_generic_method.dart
were completely bogus and needed to be changed.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2954063002 .
These tests' expectations reflect a drawback in analyzer's type
inference--it doesn't infer the correct types lists and maps
containing `null` when those structures occur outside a method body.
The new front_end type inference engine does the right thing.
Accordingly, we have to move the test to inference_new, so that we can
update its expectations without breaking analyzer's test code.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2951373002 .
This test's expectations reflect a drawback in analyzer's type
inference--it doesn't infer the correct types for calls to methods
returning `void` when those calls occur outside of a method body. The
new front_end type inference engine does the right thing.
Accordingly, we have to move the test to inference_new, so that we can
update its expectations without breaking analyzer's test code.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2953903002 .
Also, fix a minor bug in variable declaration inference that was
preventing a local variable without an initializer from having its
type properly "inferred" as `dynamic`.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2949093002 .
Fasta desugares some expressions differently in void contexts, so to
be on the safe side, we should test that null-aware invocations and
property accesses work in both void and non-void contexts.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2948843002 .
In spec mode the types aren't meaningful anyway (due to the fact that
the spec mode type system is unsound), and they don't match the
behavior of Rasta (causing bot failures).
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2953503002 .
I want to start testing that Fasta sets the static types of
conditional expressions correctly, so I need Fasta's expectations
files to include them.
This CL just adds the static types to the printing logic in
ast_to_text.dart and updates expectations so that the tests continue
to pass. I will make behavioral changes to Fasta in future CLs.
R=kmillikin@google.com
Review-Url: https://codereview.chromium.org/2949753002 .
Normally getters and setters are considered distinct and unrelated by
the type inference algorithm. However, if a getter has no declared
type and doesn't override anything, then we fall back on inferring its
type from an inherited setter, and vice versa.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2946733003 .
Paul Berry