This is a reland of 1a4cff1bd4
Original change's description:
> [VM] Remove unused flags
>
> Remove the following flags which are always ON
> --strong
> --reify_generic_functions
>
> and these flags which are not applicable anymore
> --error-on-bad-override
> --error-on-bad-type
> --enable-type-checks
>
> Change-Id: I6e1aeb68e663953f4ae49ca94ea0daa87b661900
> Reviewed-on: https://dart-review.googlesource.com/c/79431
> Commit-Queue: Siva Annamalai <asiva@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Régis Crelier <regis@google.com>
Change-Id: Ib4452c22fb05eed38820708abb648939e03b1df0
Reviewed-on: https://dart-review.googlesource.com/c/84923
Reviewed-by: Siva Annamalai <asiva@google.com>
Remove the following flags which are always ON
--strong
--reify_generic_functions
and these flags which are not applicable anymore
--error-on-bad-override
--error-on-bad-type
--enable-type-checks
Change-Id: I6e1aeb68e663953f4ae49ca94ea0daa87b661900
Reviewed-on: https://dart-review.googlesource.com/c/79431
Commit-Queue: Siva Annamalai <asiva@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Régis Crelier <regis@google.com>
This happened using APIs like `Stream.first` that set cancelOnError when
they called `Stream.listen()`. If an error is signaled, Stream internals
will call `cancel()` and wait for that future to complete before sending
the error to the resulting Future. However the `async*` implementation
class did not properly account for that possiblity, and never completed
the cancellation future in that case.
Change-Id: Ieaa35e56ee80208d7946904ea40bfd5f785ef9d6
Reviewed-on: https://dart-review.googlesource.com/c/83467
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
This is similar to the analyzer backend's optimization for fields, but
it also supports private methods and accessors.
Also fixes#34769, checks were missing for explicit covariant fields
and those are now generated (this is for fields of the form
`covariant SomeType fieldName`--implicitly covariant fields in generic
classes were already checked correctly).
Change-Id: I5ce3ed7944bdc5a9799c731c5f95e199b461b079
Reviewed-on: https://dart-review.googlesource.com/c/79432
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
Original commit message:
[dartdevc] fix#35013, move DDC off Analyzer task model
The new file pkg/dev_compiler/lib/src/analyzer/driver.dart handles
building the linked summary for a build unit, and then is capable of
doing analysis using LibraryAnalyzer.
The algorithm is very similar to analyzer_cli's build mode. The
biggest difference is that `dartdevc` has existing support for
discovering source files from the explicit source list (rather than
requiring every source to be listed on the command line). We don't want
to break that support, so there's a bit of logic to follow imports,
exports, and parts.
After the linked summary is produced, DDC gets the analysis results
(errors and resolved AST) for each library, and compiles it into a JS
module.
Change-Id: I8d1855c27f9976cad6fd9ccb567b75a613e6048c
Reviewed-on: https://dart-review.googlesource.com/c/83060
Commit-Queue: Paul Berry <paulberry@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
The new file pkg/dev_compiler/lib/src/analyzer/driver.dart handles
building the linked summary for a build unit, and then is capable of
doing analysis using LibraryAnalyzer.
The algorithm is very similar to analyzer_cli's build mode. The
biggest difference is that `dartdevc` has existing support for
discovering source files from the explicit source list (rather than
requiring every source to be listed on the command line). We don't want
to break that support, so there's a bit of logic to follow imports,
exports, and parts.
After the linked summary is produced, DDC gets the analysis results
(errors and resolved AST) for each library, and compiles it into a JS
module.
Change-Id: I7bf1ce1eca73fd036002e498de5924c488b534dc
Reviewed-on: https://dart-review.googlesource.com/c/82469
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
Mixin declarations cannot be instantiated or extended, so they should
not have constructors. Adding a compiler-generated constructor causes
us to try to add an invocation of the default superclass constructor.
Because the superclass constraint is encoded as a superclass this can
cause a spurious error that is impossible to fix.
Fixes https://github.com/dart-lang/sdk/issues/35011
Change-Id: Ia8f99d00b1a5b042da233d54f3cc1f0c6345e779
Reviewed-on: https://dart-review.googlesource.com/c/82447
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Before, e.g.
```
main() {
L: var x, y;
x = 42;
y = x;
}
```
would produce something like
```
static method main() → dynamic {
{
dynamic x;
dynamic y;
}
x = 42;
y = x;
}
```
i.e., the variable declaration was in another scope, and their usage
isn't legal.
This CL fixes that by either
a) (the normal case) not wrapping it --- the label is not used anyway.
b) (the case that cannot happen) put a label on the first part so the
output would be something like
```
L: dynamic x;
dynamic y;
x = 42;
y = x;
```
Fixes#34943.
Change-Id: I24132665dab53fb8fb024f73dd11e0d1f1945812
Reviewed-on: https://dart-review.googlesource.com/c/82063
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
Brian Wilkerson