The idea is to have more _emitXXX methods, so that different paths for
the same semantic action (e.g. implicit vs explicit 'this') call the
same _emitXXX method.
This is the first (simplest) step: assignments.
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/2039173005 .
Put type tests (is, as, type assertion) on the types as 'is', 'as' and '_check' methods.
The check
dart.check(x, core.String);
becomes
core.String._check(x);
which is more concise and allows the test to be specialized.
In one scrolling action, 224ms in dart.as and dart.check is replaced by 89ms of checks across the specializations.
R=vsm@google.com
Review URL: https://codereview.chromium.org/2012153002 .
Added 'tag' type StrongModeError, implemented by all errors that are
specific to strong mode semantics.
Failed casts throw CastError(Implementation) or StrongModeCastError.
Failed type assertions and reified coercions throw TypeError or
StrongModeTypeError.
Triaged some tests. Some pass due to now throwing a TypeError, many
pass for unknown reasons.
R=leafp@google.com
Review URL: https://codereview.chromium.org/2026133002 .
- Same errors as VM & Dartium
- Failed assertion: boolean expression must not be null
- type 'int' is not a subtype of type 'bool' in boolean expression
- All boolean conversion contexts use the same logic
- No false positives from combining null and as-bool checks in other contexts
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1993023003 .
This doesn't include the copious changes in collection_patch.dart
because I believe (1) those are quite old and (2) are dart2js specific.
The changes here have basically no effect on DDC, but it at least gets
us a little better test coverage and reduces noise in the diffs.
R=sra@google.com
Review URL: https://codereview.chromium.org/1977003002 .
we still have an init method, for better or worse, to break out of ES6 restrictions
The idea here is default Dart constructor (really an initialization method) is always called `new` instead of the class name. We already do this for unnamed factory.
R=leafp@google.com
Review URL: https://codereview.chromium.org/1965213003 .
The generated summary file matches the generated DDC sdk - i.e., it
does not include dart:io. I modified the codegen_tests to the summary
and had to prune the parts of unittest that relied on dart:io.
Paul / Konstantin: can one of you please look at the summary part?
Bob: can you please look at the unittest changes?
R=rnystrom@google.com, scheglov@google.com
Review URL: https://codereview.chromium.org/1982853002 .
These libraries are not supported by dev_compiler, hence the source
files that declare them don't exist in tool/input_sdk/lib. Removing
them from `libraries.dart` will allow the analyzer to build a summary of
dev_compiler's fork of the SDK.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1980963002 .
This produces output closer to what we get in bazel - you may want to use this to analyzer load perf. It will also let me drill down on individual compile steps.
Using process & async adds complexity, but a lot of speedup over doing it linearly.
R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1965013003 .
We used to emit an eager field if a static was overriding a static field
in a superclass because this is valid ES6. However, even if the static
field is not synthetic in the superclass, it might still be emitted as a
lazy static. The safest way is just to emit a lazy field for static
overrides always.
fixes#522R=jmesserly@google.com
Review URL: https://codereview.chromium.org/1966763004 .
Leaf Petersen