- 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 .
it is unused now since the extension type system replaced it.
there's a potentially interesting use case supported, e.g. ES6 subclasses of JS Array, but we can ignore that for now (IMO)
R=sra@google.com
Review URL: https://codereview.chromium.org/1967743005 .
We initially hard coded a few of these. That worked until native_typed_data and html were added. Those two libraries have a lot of native types.
This also fixes TypeRep to extend dart:core Object, and fixes the dart:_runtime so we can write Dart classes. Cleans up a few of the JS builtins as well.
R=vsm@google.com
Review URL: https://codereview.chromium.org/1962823002 .
I started trying to get the convert tests all cleaned up and passing
but realized I was going down a rathole. So, for now, all of the slow
or failing ones are just skipped.
BUG=
R=sra@google.com
Review URL: https://codereview.chromium.org/1965563003 .
John Messerly