Run `pkg/status_file/bin/normalize.dart` across all status files.
This should solve most presubmit warnings about "existing and possibly
new status file issues".
There are remaining issues in pkg/front_end/testcases/strong.status and
pkg/front_end/testcases/text_serialization.status which will need to be
fixed manually.
Change-Id: Iceae8992c4907442481590d75c1b0a84ce29521b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/106726
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
This feature is under development in the front end. Testing it on the
runtimes leads to numerous spurious status changes. Skip the tests
for now. The intent is that when a backend change causes a test to
start passing, then that test will be un-skipped.
Change-Id: I6c8c1f45315607039240c3edc61ba8340ae9cda0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/96902
Commit-Queue: Kevin Millikin <kmillikin@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Auto-Submit: Kevin Millikin <kmillikin@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Add a new kind of constant context in the body builder for expressions
that must be constant but where constness is not inferred.
This context is used for parameter default values and initializing
expressions for non-final fields in classes containing at least one
const constructor.
Fixes https://github.com/dart-lang/sdk/issues/34191
Change-Id: I200ca88586b19335b185dad0839dfad4eef1f75f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/93520
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Peter von der Ahé <ahe@google.com>
This improves the default JS display of exceptions/errors from DDC
compiled code. This gives a better "default" experience if JS code
(or a JS engine, like browers/Node.js) ends up catching Dart exceptions.
Change-Id: Ib2dda6eee710f8b536d5ed7223e0101310a137b3
Reviewed-on: https://dart-review.googlesource.com/c/84446
Commit-Queue: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Vijay Menon <vsm@google.com>
This reverts commit a0d576e6cd.
Reason for revert: Turned many buildbot builders red. Use the "Choose tryjobs" button to run more configurations on this type of commit. Use the "tools/bots/approve_results.dart" tool to update expectations for builders running the new workflow
Original change's description:
> Add more tests for async*/await-for operations.
>
> Change-Id: I2c8ffb8a6738b8dee43cfdf85be0c54d2735b6cc
> Reviewed-on: https://dart-review.googlesource.com/c/85391
> Commit-Queue: Lasse R.H. Nielsen <lrn@google.com>
> Reviewed-by: Leaf Petersen <leafp@google.com>
TBR=lrn@google.com,leafp@google.com
Change-Id: I81830c3fc565b62e98538feba9bd64c6dd11dd51
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/86023
Reviewed-by: William Hesse <whesse@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>
Declared mixins are not classes and should not be able to be
extended. This was not allowed by the analyzer anyway and since the
mixin declaration feature is not launched, we are not breaking any
code by making this bug fix.
Change-Id: Ia49dd207213accb16ad8dd819a22844d65ccfcab
Reviewed-on: https://dart-review.googlesource.com/c/79524
Reviewed-by: Aske Simon Christensen <askesc@google.com>
class in a foreign library.
This CL changes the predicate which is used to decide whether to
generate noSuchMethod forwarders such that it returns true whenever
the class in question has a user defined no such method or the
enclosing library of the class is different from that of the member.
Closes https://github.com/dart-lang/sdk/issues/33727
Change-Id: I0ffcbb8c8bdd69e4261bcefce2251d31babc19cf
Reviewed-on: https://dart-review.googlesource.com/c/79209
Commit-Queue: Daniel Hillerström <hillerstrom@google.com>
Reviewed-by: Dmitry Stefantsov <dmitryas@google.com>
The parser now generates a ConstructorWithTypeArguments error and a new
handleInvalidTypeArguments event after a begin/endTypeArguments event pair
when those type arguments are in a syntatically invalid location.
For example: `new C.n<int>();` in
```
class C<T> { T f; C.n() {} }
main() { var x = new C.n<int>(); }
Most listeners handle this event by dropping the invalid type arguments,
but AstBuilder now preserves those invalid type arguments in the AST
to support better code quick-fixes/quick-assists/refactoring.
Change-Id: I5b22bd4903cd9ee3645936b9a108598b603cf9ca
Reviewed-on: https://dart-review.googlesource.com/c/79300
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Dan Rubel <danrubel@google.com>
Dart for-in loops allow `var x = [1]; for (var x in x) {}`, which is not
allowed in JS. If this pattern is detected, a temporary variable is
introduced so the for-in initializer expression is evaluated outside of
the JS for-of loop.
(This issue seems to be unique to for-in loops. For loops and other
kinds of variable declarations of the form `var x = ...` are not
allowed to use `x` in the initializer, even if `x` is declared in an
outer scope.)
Also fixes an out-of-date comment in the DDC+Analyzer backend.
Change-Id: I35b272a5a311f7b6f104cc82a99cc83a6ed5c247
Reviewed-on: https://dart-review.googlesource.com/c/79142
Commit-Queue: Alan Knight <alanknight@google.com>
Auto-Submit: Jenny Messerly <jmesserly@google.com>
Reviewed-by: Alan Knight <alanknight@google.com>
The CL is reverted because it didn't account for the case when a check
of a user-specified type argument against the bound depends on another
type that is only known after type inference is done.
Change-Id: I1fd140af95ed37b9191a5b161a281d4639e3453f
Reviewed-on: https://dart-review.googlesource.com/c/79048
Commit-Queue: Dmitry Stefantsov <dmitryas@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>