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 .
I'm about to start introducing usages of TypeParameterType.bound, and
nearly all of the usage sites will need to fall back on
TypeParameter.bound if there is no bound stored in the
TypeParameterType. This CL places the fallback behavior in the
TypeParameterType.bound getter so that we won't have to duplicate it
at every usage site (and risk making mistakes). The few call sites
that don't want the fallback behavior (such as the one in
ast_to_binary.dart) can avoid it by referring to
TypeParameterType.promotedBound directly.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2952883003 .
Inline instance object hash code into object header on 64 bit.
64 bit objects have 32 bits of free space in the header word.
This is used for the hash code in string objects. We take it
for the default hash code on all objects that don't override
the hashCode getter.
This is both faster and a memory reduction. Eg it makes the
MegaHashCode part of the Megamorphic benchmark 6 times faster.
This is a reland of https://codereview.chromium.org/2912863006/
It fixes issues with the 32 bit compare-swap instruction on
ARM64 and fixes a fragile tree shaking test that is sensitive
to which private methods are in the core libraries.
R=kustermann@google.com, vegorov@google.com
BUG=
Review-Url: https://codereview.chromium.org/2954453002 .
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 .
On a switch fall through error, Fasta currently generates
```
throw new core::FallThroughError::•();
```
which generates the error-message via the VM:
```
'null': Switch case fall-through at line null.
```
This introduces a new constructor taking a url and a linenumber,
which then can give a better error message.
BUG=
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2951453002 .
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 .
This mimics the behaviour of the source-based pipeline,
i.e. instead of "manually" calling _AssertionError._create and giving
the correct parameters (wrong parameters, actually), use the helper
method _AssertionError.ThrowNew.
BUG=
R=ahe@google.com, vegorov@google.com
Review-Url: https://codereview.chromium.org/2940283002 .
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 combines the two parts of top level type inference
(determining dependencies and inferring a type) into a single
operation.
The technique is: instead of evaluating top level types in
topologically sorted order (which requires that we figure out the
dependencies first, so that we can do topological sorting), we simply
iterate over the fields requiring inference and begin inferring them
in whatever order they are encountered. If, while trying to infer the
type of one field, we discover a reference to field that hasn't been
type inferred yet, we make a recursive call to infer the second field.
If this recursion leads to a loop, then we mark all of the fields in
the loop as participating in a circularity (and set their types to
`dynamic` for error recovery purposes).
To facilitate experimentation, I've left the old code in place, but
disabled it using a const bool `fusedTopLevelInference`. 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 there are some minor user-visible behavioral changes:
- When there is a circularity, we no longer consider the entire
strongly connected component to be part of the circularity; we only
consider the loop formed by following the first unresolved
dependency of each field. (I did this because of ease of
implementation, and because it made it easier to reassure myself
that the outcome of the algorithm is independent of the order in
which fields are visited). See
pkg/front_end/testcases/inference_new/strongly_connected_component.dart
for the user-visible consequence of this change.
- We no longer need to speculatively assume that method invocations
depend on the types of their parameters when not supplying generic
types; now they only depend on the types of their parameters when
the method being invoked is known to be generic. See
pkg/front_end/testcases/inference_new/dependency_only_if_generic_method.dart.
- We no longer need to speculatively assume that invocations of `+`,
`-`, `*`, and `%` depend on the types of their RHS; now they only
depend on the types of their RHS when the type of the LHS is
`int`. See
pkg/front_end/testcases/inference_new/dependency_only_if_overloaded.dart.
R=sigmund@google.com
Review-Url: https://codereview.chromium.org/2942623004 .
Paul Berry