All variable declarations encountered by type inference are now of
type KernelVariableDeclaration, so we no longer need a hack to handle
ordinary VariableDeclaration objects.
Removing the hack avoids covering up bugs.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2961723002 .
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 .
Analyzer does not infer switch cases correctly (it uses an empty
context for the case expression, instead of the type of the switch
expression), so the tests are in inference_new.
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2953423002 .
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 .
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 .
I started implementing using of UnlinkedUnit, and found that I like
isShow and names better. Also, parts are always only URIs. And I think
that we are not going to need setters.
R=paulberry@google.com
BUG=
Review-Url: https://codereview.chromium.org/2936833003 .
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 .
The method is used to create an instance of a backend target class.
CompilerCommandLine already has the necessary information for this ("target"
name string and "strongMode" flag). Additionally, a backed target instance is
now not created in fasta.dart/parseScriptInFileSystem, but should be passed at
the call site.
R=ahe@google.com, scheglov@google.com
Review-Url: https://codereview.chromium.org/2932513003 .
hand.
The example includes:
- an interactive UI that lets you trigger reloads without typing commands
- a wrapper of the incremental kernel generator that invalidates files based on
modification time stamps
BUG=
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2928483005 .
This updates the fasta scanner to translate the remaining
previously untranslated error codes so that they will be seen
by the analyzer when the fasta scanner is used by analyzer.
R=ahe@google.com
Review-Url: https://codereview.chromium.org/2923113002 .
* add cmdline option so that analyzer will use the fasta scanner
* refactor handling of unterminated strings
Use -DuseFastaScanner=true to use the fasta scanner
rather than the analyzer scanner
R=scheglov@google.com
Review-Url: https://codereview.chromium.org/2919163002 .
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 .
