This regressed in https://dart-review.googlesource.com/c/74664/.
In Analyzer FunctionType.typeFormals returns TypeParameterElements
instead of TypeParameterTypes; it is not safe to assume non-null bound
for elements.
Also fixes & clarifies the intent of _canEmitTypeAtTopLevel (formerly
_typeIsLoaded). There was no reason to visit the typeFormals, as generic
function types can always be emitted into the module.
Change-Id: Ia8b9271c2d1b66dca934d032dcbbe4fe89146f1b
Reviewed-on: https://dart-review.googlesource.com/76746
Reviewed-by: Alan Knight <alanknight@google.com>
- option --no-preview-dart-2 will now result in an error
- change aot-assembly build rule to generate AOT snapshot using Dart 2
- generate coresnapshot using Dart 2 (this snapshot is not used yet, next CL which switch the isolate create code to use this snapshot)
- by pass all Dart1 test runs in the status file
- change the default compiler setting in test.py to use dartk
- have test.py not pick up any configuration for --no-preview-dart-2
Change-Id: Ia136943ebfd0fed0c52683b330745b3e2c7a7ce6
Reviewed-on: https://dart-review.googlesource.com/75820
Reviewed-by: Zach Anderson <zra@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
If a field is initialized with null (either explicitly or implicitly),
field store can be omitted in bytecode. In such case, bytecode should
still convey the information about this initialization to VM for
field guards to work correctly.
Change-Id: I1fd45b858c3c521b97fa5dbffe0e15b1ea75d92f
Reviewed-on: https://dart-review.googlesource.com/76060
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
To avoid causing unrelated tests to start failing, the tests have been
modified to avoid running afoul of the analyzer toplevel inference
limitations. (Note that we still have adequate test coverage in
pkg/front_end/testcases that the front end isn't subject to these
limitations).
Change-Id: I7b8f84a358d0e8891025b24143117c39d1b7dd69
Reviewed-on: https://dart-review.googlesource.com/75389
Reviewed-by: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The bleeding edge console revealed that status files for
dartk-checked-linux-release-x64 configuration needed to be updated.
Change-Id: I7015427f55436947aebd019212765c5f3937f846
Reviewed-on: https://dart-review.googlesource.com/75440
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
This makes closed world computation take the static type of the receiver
into account and removes non-live members from the J-world.
Change-Id: I5547aaae4685c6417a94916df0bc4e621296ce8d
Reviewed-on: https://dart-review.googlesource.com/72643
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Implement the feature spec for checking returns against inferred
function return types:
https://github.com/dart-lang/sdk/blob/master/docs/language/informal/invalid_returns.md
with the change that an invalid return without a subexpression is
a warning, not an error. This is because it is a warning in the
analyzer and it would be a breaking change to turn it into an
error.
The check for valid returns is moved to exactly where we handle
returns, rather than in ensureAssignable which is used as a
helper in a lot of places. A bug in type inference was fixed: we
would use `void` for the type of return without a subexpression
instead of `null`. To accommodate that we would use a
non-standard subtyping relation for returns. This could lead to
us inferring a return type of `void` in cases where we should
not.
Change-Id: Iee9ece9c722f47efa305f49490d3022d0bbb9f44
Reviewed-on: https://dart-review.googlesource.com/72403
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
E.g. `new Map<String>` is now reported as an error.
Note that this does not add a check for whether correct types are given,
so e.g.
```
class Foo<X extends num> {}
main() {
new Foo<String>();
}
```
is not caught by this fix.
Fixes#32972, #32281.
Change-Id: I57513b5c13865a828890775c8e14f7433d00bdbe
Reviewed-on: https://dart-review.googlesource.com/72382
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Removed all sections labeled $compiler == dart2js and !$fasta.
Removed $fasta from all sections with $compiler == dart2js and merged
with existing sections as appropriate.
Some additional cleanup and normalization.
Change-Id: I8b93283a2cce22ce60e29d364c8d0e70dccbb6e3
Reviewed-on: https://dart-review.googlesource.com/71840
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
If a JS class is not found (because it's not loaded yet), dartdevc
should handle this gracefully. However the code assumed that the class
would not be nested in a module that itself has not been loaded. That's
fixed in this change.
Change-Id: I2de8f4b85e8063dea31ea257aca9721702c6ea7a
Reviewed-on: https://dart-review.googlesource.com/72065
Reviewed-by: Vijay Menon <vsm@google.com>
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Bug: https://github.com/dart-lang/sdk/issues/33022
This commit adds an error when a final field is not initialized at all
(and there is at least one generative constructor). A later commit
will add an error for the case where a field is initialized by some,
but not all, generative constructors.
A number of classes in the Dart2js and DDC support libraries use
uninitialized final fields to indicate getters in the corresponding
native classes. This commit adds a temporary whitelist for the
affected files, which can be removed when the fields have been
replaced by external getters.
This is tracked by https://github.com/dart-lang/sdk/issues/33762
Change-Id: I6b5cee230c7cd5554da2b61da7ebddb6b0b9396e
Reviewed-on: https://dart-review.googlesource.com/63781
Reviewed-by: Daniel Hillerström <hillerstrom@google.com>
Add simplified unittest replacement to package:expect.
(It is used in multi-tests, so it needs to be in an accessible place without using ".." in its path).
Change-Id: I60aa212ed67ffbdda17ca18fce1cdff16237f4fe
Reviewed-on: https://dart-review.googlesource.com/65700
Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
Reviewed-by: Jenny Messerly <jmesserly@google.com>
This CL adds support to build.py and test.py for building/testing
a VM with the interpreter on x64, e.g.:
$ ./tools/gn.py -m release -a x64 --bytecode
$ ./tools/build.py -m release -a x64 --bytecode runtime
$ ./tools/test.py -m release -a x64 -r vm -c dartkb language_2
Change-Id: I956d23790636609d4a2e71129481fcbd7afef9a0
Reviewed-on: https://dart-review.googlesource.com/65206
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
server is started.
When the incremental compiler is used it accumulates state that
increases the footprint of the process. This state is needed only
when the 'reload' or 'expression evaluation' functionality is used
in the debugger.
Currently in the VM we do not have a good way of detecting when the
debugger will be used as the vm service observatory functionality
can be turned on dynamically after the program has started.
This CL turns on the incremental compiler only when command line options
are used to start the observatory server. We could run into issues with
'expression evaluation' when the observatory is started dynamically after
the program is loaded.
Change-Id: I18c17698622071bca428018f7fdac1a84b0f195e
Reviewed-on: https://dart-review.googlesource.com/64667
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Martin Kustermann