When landed, CL 1789553003 turned out to cause bot failures because
some libraries outside the compiler are importing compiler libraries
which have been updated. For instance, the tests in 'compiler/dart2js'
depend on several internal elements of the 'dart2js' compiler.
This CL updates these external dependents to work with the modified
library structure and class APIs of the compiler. A small adjustment
was applied to 'dart2js_incremental' as well.
No further dependents are believed to exist: Grepping in sdk for
relevant imports does not reveal any further imports of any of the
libraries in the compiler where the "interface" has changed, and
external clients are not supported (that is, imports in arbitrary
github repositories may or may not break if they use the compiler
internals, but we do not support this type of dependency so we won't
do anything to protect them against that type of breakage).
R=johnniwinther@google.com
Review URL: https://codereview.chromium.org/1864433004 .
In preparation for support for generic methods (with an associated
command line option), this CL introduces a `ParserOptions` class and
uses that to pass the existing option `enableConditionalDirectives` to
all parsers. With that, the addition of an `enableGenericMethodSyntax`
option will be concise and well localized.
It is necessary to keep a `ParserOptions` object in `Parsing`, because
that's the only convenient channel for providing the options to the new
`Parser` and `ClassElementParser` created from the top-level function
`parse` in 'partial_elements.dart', and a from
`PartialClassElement.parseNode`, respectively.
The `ParserOptions` class is located in 'parser.dart'; from the current
import structure the most natural choice might be to put it in
'element_listener.dart', but considering the nature of that file it
seems less natural: What does `ParserOptions` have to do with element
listeners? So I put it in 'parser.dart', even though this causes a few
additional import statements.
R=johnniwinther@google.com, sigmund@google.com
Review URL: https://codereview.chromium.org/1789553003 .
Before the mapping from HInstruction names to printed representations
used by the tracer was arbitrary. Change it to use the HInstruction
name with a colon separating the arguments from the instruction name.
The first colon on the line is recognized by the tool as delimiting
the opcode.
Seeing the precise structure of the IR is more important than
having human-writable surface syntax.
BUG=
R=sra@google.com
Review URL: https://codereview.chromium.org/1819833002 .
In the case of ssa, I also removed references to AST nodes in ssa nodes that were unused, so now only the builder imports the AST.
I also got rid of unused imports from everywhere else in the code.
R=sra@google.com
Review URL: https://codereview.chromium.org/1762723002 .
NodeList mixes in IterableMixin<Node>. This makes the object bigger,
costing ~3% extra size for the Dart AST. (10MB out of 350MB)
One idea would be to revert this change and make all the for-in sites use
the .nodes member.
Link<T> now implements Iterable<T>, with missing methods added.
IterableMixin could not be used since Link has a const constructor.
I would like to see Link<T> replaced with fixed length lists or
unmodifiable lists.
A couple of other classes were modified to return an Iterable.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1783053005 .
There is no need to set the runtime type on an object whose
type arguments are all 'dynamic'.
Also use a more precise precondition for eliminating a
ReadTypeVariable access.
BUG=
R=kmillikin@google.com
Review URL: https://codereview.chromium.org/1784263002 .
- No longer attribute queries to type inference. Queries are attributed to client.
- Remove vestigial CPA code
- Don't compare target sets for additions and deletions if they are
the same (most of the time we revisit the dynamic call site due to
a change in a returned result).
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1777393003 .
Removing the `_assignments` and `users` collections from TypeInformation
nodes causes interior nodes (e.g. Phi, Narrow) to become unreachable and
available for GC. This seems to trim 1%-5% off the final heap of an SSA
compile.
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1776533002 .
This adds a source mapping to variable declarations in the beginning of a JS function, that points to the start of the corresponding Dart method:
foo: function() {
var a, b;
^
maps to
foo() {
^
R=sigmund@google.com
Review URL: https://codereview.chromium.org/1772703002 .
Previously, the "receiver" of an InvokeMethod would be either be the
"Dart receiver" or an interceptor, depending on the calling convention.
Likewise, the argument list was possibly prefixed by the Dart receiver.
Now, the receiver is always the Dart receiver, and the arguments are
the Dart arguments and the interceptor is in a field specific for the
interceptor.
The old way was very inconvenient in the CPS, it has led to several
bugs already, and it's just unintuitive that "receiver" can mean two
very different things.
FunctionDefinition no longer has a thisParameter, but
instead a receiverParameter and an interceptorParameter. These are
named to correspond exactly with the names used in InvokeMethod.
The concept of 'this' has been removed from the CPS IR to hopefully
avoid confusion between 'Dart this' and 'JS this'. There is now only
receiver and interceptor, and which one corresponds to the JS 'this'
is irrelevant.
The Tree IR has not changed. The Tree IR builder is thus responsible
for translating the calling convention into the JS receiver and
argument list. The Tree needs to know the order in which the operands
are evaluated, so it makes sense to keep this form in the Tree.
R=sra@google.com
Review URL: https://codereview.chromium.org/1761903002 .
Harry Terkelsen