The hot reload runner currently only supports d8, but I plan to add support for Chrome and VM execution.
Notable changes:
* Creates `package:reload_test` with helpers for running this suite.
* Updates the module loader with D8-specific branches and hooks for hot reload/restart.
* Exposes DDC runtime variables via a `HotReloadTestRuntime` API.
* Ports constant equality hot restart tests from webdev/dwds (validated to fail if either cache-clearing mechanism fails).
* Partially rolls DDC's d8 preamble forward (towards dart2js's).
* Wraps D8's timer implementation with custom timeout logic to better match Chrome's timing semantics when executing with native JS async.
Tests for the framework and matrix updates will be added in an upcoming change.
Change-Id: I2773b29f464cfd0330e4c653c05e117ae150b4a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350021
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
Fixes https://github.com/dart-lang/sdk/issues/55024
The patch files for these operators return a bool, whereas
the public API returns a JSBoolean. Since there's only one
possible return type, we should make them return bool for
convenience. Boolean conversion is also inexpensive on
dart2wasm, so that shouldn't be an issue.
Also adds helpers to operator_test to make sure any JS values
are converted before they're compared, adding additional type
checking through the conversion.
CoreLibraryReviewExempt: Fixes type mismatch in backend-specific library.
Change-Id: I7ff2e334e817e6e7d7d8d5091a4e5d570a496b03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354702
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
In the following expression types, the static type is computed using
the least upper bound ("LUB") of their subexpressions (adjusted as
appropriate to account for the null-shorting behaviors of `??` and
`??=`):
- Conditional expressions (`a ? b : c`)
- If-null expressions (`a ?? b`)
- If-null assignments (`a ??= b`)
- Switch expressions (`switch (s) { p0 => e0, ... }`)
This can lead to problems since the LUB computation sometimes produces
a greater bound than is strictly necessary (for example if there are
multiple candidate bounds at the same level of the class hierarchy,
the LUB algorithm will walk up the class hierarchy until it finds a
level at which there is a unique result). For a discussion of the kind
of problems that can arise, see
https://github.com/dart-lang/language/issues/1618.
This change improves the situation by changing the analysis of these
four expression types so that after computing a candidate static type
using LUB, if that static type does not satisfy the expression's
context, but the static types of all the subexpressions *do* satisfy
the expression's context, then the greatest closure of the context is
used as the static type instead of the LUB. This is the algorithm
proposed in
https://github.com/dart-lang/language/issues/1618#issuecomment-1507241494.
This is theoretically a breaking change (since it can change code that
demotes a local variable into code that doesn't, and then the demotion
or lack of demotion can have follow-on effects in later code). So it
is implemented behind the `inference-update-3` experiment
flag. However, in practice it is minimally breaking; a test over all
of google3 found no test failures from turning the feature on.
Since one of these expression types (switch expressions) is
implemented in `package:_fe_analyzer_shared`, but the other three are
implemented separately in the `package:analyzer` and
`package:front_end`, this change required modifications to all three
packages. I've included tests for the new functionality, following the
testing style of each package. I've also included a comprehensive set
of language tests that fully exercises the feature regardless of how
it's implemented.
Since `package:front_end` has many different implementations of `??=`
depending on the form of the left hand side, I've tried to be quite
comprehensive in the language tests, covering each type of assignable
expression that might appear to the left of `??=`.
Change-Id: I13a6168b6edf6eac1e52ecdb3532985af19dbcdf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353440
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
Modifies a test to check that object literals that are
assumed to not contain a parameter actually don't
contain that parameter.
Change-Id: I2e7952c696ed22cd2d8e59d72cb1a537a61c6b6e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355202
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This CL adds more of the type operations required in the subtype
constraint gathering algorithm into the shared type operation
class. The added operations are used in the constraint gathering
algorithms in the Analyzer and the CFE.
Part of https://github.com/dart-lang/sdk/issues/54902
This is a reland of
https://dart-review.googlesource.com/c/sdk/+/346840
Change-Id: I99086cfc3cd56db40055e9bb8e23acec8bdf830b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354622
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Gives the constructor optional parameters for providing
more information that can be used in the `toString` message,
and the `stackTrace` getter.
Makes the `iterable.wait` and `record.wait` extension methods
provide such information, so that the `toString` will always
contain the text of *one* of the errors.
(No issue, problem with logging was brought up in chat.)
Change-Id: I5f9a20ad0af0c64a2e7ff3cdb56f187a5cf5a3ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353080
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Issue https://github.com/dart-lang/sdk/issues/54628 raised the issue
that the static analysis of `await e` behaves in unexpected ways when
the static type of `e` is a subtype of a future related type, rather
than just a plain `Future<T>` or `FutureOr<T>` for some `T`.
This CL adds a test that assumes the update to the language
specification which is performed by the PR
https://github.com/dart-lang/language/pull/3574. Hence, this CL
should ONLY BE LANDED if and when that PR is landed.
Change-Id: Ib8acb77e24ffbceb0b4034d3b23a0f4fef8e3d1c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354020
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The old version of language/void/void_type_usage_test.dart had some
faults (compile-time errors were expected, but they weren't reported
by tools and yet the test run succeeded). The failures were caused by some amount of duplication in the labels (a handful of duplicate labels from a set of about 450 labels, that is, it wasn't immediately obvious). This CL updates the test to use the new test expectation syntax (`// ^^^^`) and adjusts the expectations to match the currently reported error messages, plus the ones about `void` that are missing.
Note that this test went through a phase where I believed that we had about 260 failures (130 CFE and 130 analyzer), but they turned out to be a consequence of migrating this test incorrectly from being a multi test into a form where it uses the current test expectation comments (`// ^^^` and such). At this point we just have 3 failures (all on expressions of the form `e += 1`), all with the CFE.
Bug: https://github.com/dart-lang/sdk/issues/31883
Change-Id: Ib1ceb56326a5847e3ca23ac0ee655eee65f0d76f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350921
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
The test LibTest/collection/ListBase/ListBase_class_A01_t02 takes
more than 10 minutes to be precompiled in debug mode, due to
a known issue.
Skipping this test on the CI and CQ because it causes deflaking problems
when timing out. The problem is being tracked already in an issue.
Bug: https://github.com/dart-lang/sdk/issues/54974
Bug: https://github.com/dart-lang/sdk/issues/21708
Change-Id: Ib05e0f18baac684cf3317dbc2171a5a585e04f98
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354844
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The web platforms used to invent a spurious stack trace when reading
`Error.stackTrace` before the object was thrown.
They now return `null` instead, if there is no underlying JS error object,
matching specified behavior.
Fixed bugs in async error throwing in dart2wasm:
* `throw` in an async function did not set the stack trace on an error.
Now calls `Error._throw` instead of just a direct Wasm "throw".
* `async*` functions did not capture the stack trace of a throw
that ended the function body, which means it called
`StreamController.addError` with only one argument.
That then resused the stack trace from an `Error` throw instead
of the correct stack trace.
Added tests.
Change-Id: I1d9fa8d9e18076a7fe28254b60b950866cd550a7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354021
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Use the new Throw.forErrorHandling AST flag to ignore synthetic error
handling statements in coverage. When the flag is found on a throw node,
all the TokenPositions on the child nodes are set to kNoSource.
Questions for reviewers:
- Are there any VM use cases that need the real TokenPosition here?
- Is there a better way of encoding this flag in the TokenPosition?
- Should we add a new sentinel TokenPosition instead?
Bug: https://github.com/dart-lang/sdk/issues/54005
Fixes: https://github.com/dart-lang/sdk/issues/53519
Fixes: https://github.com/dart-lang/sdk/issues/54941
Change-Id: Ic44fe2fa0359188b890d5ed762e3ff8c593c850d
TEST=SourceReport_Regress53519_Destructuring
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353920
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Liam Appelbe <liama@google.com>
https://dart-review.googlesource.com/c/sdk/+/352863 added an import
before the lines that throw an error, causing the checks in these two
tests to be off by one.
TEST=standalone/dwarf_stack_trace_invisible_functions
standalone/dwarf_stack_trace_obfuscate
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-release-arm64-try,vm-aot-linux-release-x64-try
Change-Id: Ia2830bf6b49d991bb21a9973acb4c1888f9f441b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354222
Auto-Submit: Tess Strickland <sstrickl@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Those timing out tests cause CI infra issues (purple bots)
on deflaking.
Issue https://github.com/dart-lang/sdk/issues/55025
Change-Id: Ibdc3766e0e482f180c03acc987c3323a3574647c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354621
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Auto-Submit: Martin Kustermann <kustermann@google.com>
* We migrate the `dart:developer` implementation of dart2js to
static interop.
* We make dart2wasm use the same implementation as dart2js.
Closes https://github.com/dart-lang/sdk/issues/54991
Change-Id: I7873edc7e804500c8eca878367d9045c98a1c2e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354101
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
This covers a failure in language/macros/json/json_serializable_diagnostics_test.dart
Change-Id: I751a58db6316ef2d9bb42533e279ab5fa49d1fd0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354042
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
`dart:mirrors` is not supported in AOT mode.
Bug: https://github.com/dart-lang/co19/issues/2546
Change-Id: I2b0d42df911c6f185e72239f4786a87c535de535
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353522
Reviewed-by: Siva Annamalai <asiva@google.com>
Auto-Submit: Sergey Grekhov <sgrekhov22@gmail.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
The only expected exceptions at this point are DiagnosticException and MacroException subtypes; everything else is a bug in the implementation.
Tweak the diagnostic to explain that it's due to a bug in the macro. Add the exception message and stack trace as a context message, and a fix hint to contact the author.
Add a language test.
Retry landing with updates to `pkg/analyzer/test/summary/macro_test`.
R=jensj@google.com, scheglov@google.com, sigmund@google.com
Change-Id: Iebc3df784922dcb6ef112ba8d023d5388516373b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352361
Reviewed-by: Jake Macdonald <jakemac@google.com>
Auto-Submit: Morgan :) <davidmorgan@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Also modified `File::GetType` on Windows to correctly report the type of broken links as notFound.
Windows fixes:
co19/LibTest/io/Link/createSync_A04_t08
co19/LibTest/io/Link/createSync_A04_t10
co19/LibTest/io/Link/createSync_A04_t12
co19/LibTest/io/Link/createSync_A04_t14
co19/LibTest/io/Link/createSync_A04_t16
co19/LibTest/io/Link/createSync_A06_t01
co19/LibTest/io/Link/createSync_A06_t03
co19/LibTest/io/Link/createSync_A06_t06
co19/LibTest/io/Link/createSync_A06_t08
co19/LibTest/io/Link/create_A04_t08
co19/LibTest/io/Link/create_A04_t10
co19/LibTest/io/Link/create_A04_t12
co19/LibTest/io/Link/create_A04_t14
co19/LibTest/io/Link/create_A04_t16
co19/LibTest/io/Link/create_A06_t01
co19/LibTest/io/Link/create_A06_t03
co19/LibTest/io/Link/create_A06_t06
co19/LibTest/io/Link/create_A06_t08
co19/LibTest/io/Link/resolveSymbolicLinksSync_A01_t01
co19/LibTest/io/Link/resolveSymbolicLinks_A01_t01
Bug:https://github.com/dart-lang/sdk/issues/53848
Bug:https://github.com/dart-lang/sdk/issues/45981
Change-Id: I3d156f38540089d8adb12dbb79d0477330d9eb07
Tested: updated unit tests plus fixes existing tests
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335940
Commit-Queue: Brian Quinlan <bquinlan@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
This looks like it was an oversight--previous to this change, there
was zero test coverage for this case.
Change-Id: I4301a3ba90aedce3b0fcd901649c370cba522f4e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Currently hash code for a closure is the hash code of it's runtime type.
This causes a lot hash collisions in some apps and cause performance
issues.
With this patch we now use captured objects in closures when calculating
hash codes.
The hash codes are now:
- For tear-offs:
mix(receiver hash, closure runtime type hash)
- For instantiations:
mix(instantiated closure hash,
hashes of captured types)
Note that an instantiation can be of a tear-off, in which case
"instantiated closure hash" will calculate the tear-off hash as above.
- For others (function literals, static functions), the hash is the
identity hash.
Fixes#54912.
CoreLibraryReviewExempt: Mark private corelib function as entry-point in Wasm
Change-Id: I6a123fdc690237f543bb8bf832f0f8119d013a55
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353162
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Fixes: #54971
Change-Id: I033c8ba78e6cdcf26dce9cae8998308a595a37e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353262
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
This looks like it was an oversight--previous to this change, there
was zero test coverage for this case.
Change-Id: Icba1381c389af37ab4fe38f345cc78fe6c01d7f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/353226
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
If a target `_Future` is chained to another source `_Future`,
then it's because the target will complete with the same
result as the source future. Instead of keeping both
alive with a listener on the source which completes the target,
instead the target moves all its listeners to be directly on
the source, and keeps a link to the source in case more listeners
are added later.
The idea is that most futures are unreferenced after they have
had their first listener, so the target future has a chance
to be GC'ed.
If the target future has `.ignore()` called, and has no listener,
then the source completing with an error should not cause the
error to be uncaught. Without the optimization, the source would
have had a listener, and the target would ignore the error.
To simulate that, the source now gets a copy of the target's
`_ignoreUnhandledErrors` flag.
This is still not precisely the same as it would be without the
optimization. If *two* target futures are chained to the same source,
and only one of targes has `.ignore()` called, then this
implementation will make the uncaught error not be reported,
where it technically should.
(An alternative would be to *not* use chaining for futures
with `ignore()` called on them. But those are precisely futures
that are likely to be GC'able, because someone has already said
that they don't care if the future complete with errors.)
Fixes#54943
Bug: https://github.com/dart-lang/sdk/issues/54943
Change-Id: I0dbb4919ce2ea612d66539862fa0eb188aab8287
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352908
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Fixes https://github.com/dart-lang/sdk/issues/54801
Object literal constructors need to be explicitly handled when
determining a member is JS interop or not in dart2js as it does
not require any @JS annotations.
Change-Id: Iee99375439057844485aa3f5cd88f85f5d03ae06
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349840
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This CL contains several small bug fixes:
- The context is only used for type inference if it is a record type
with the same shape as the record literal. Previously, if the
context was a record type with a different shape than the record
literal, the analyzer would attempt to do an approximate match
(using the context from any matching named fields, and from all the
positional fields that were in common between the context and the
literal). At first glance, it might seem like this would only matter
for erroneous code (since record shape mismatches typically lead to
compile-time errors). But if the context arises from a local
variable promotion, then a mismatch doesn't lead to a compile-time
error; it simply leads to a demotion. So the difference is
observable for non-erroneous code.
- If one of the fields is implicitly downcast from `dynamic`, the
static type of the field's expression remains `dynamic`. This makes
the behavior of dynamic downcasts inside field literals consistent
with all other implicit dynamic downcasts.
- If one of the fields is implicitly downcast from `dynamic`, the
downcast is made to the greatest closure of the context. Previously,
the downcast was made to the context itself, which meant that it was
possible to create static types containing the unknown type,
violating one of the key assumptions of the Dart type system.
- If one of the fields has a static type of `dynamic`, and `dynamic`
is a subtype of the greatest closure of the context (e.g. because
the context is `Object?`), no dynamic downcast is
performed. Previously, a dynamic downcast _was_ performed, meaning
that the static type of the resulting record literal would have
`dynamic` in a spot where `Object?` should be.
This brings the analyzer behavior into line with the spec and the
front end, with one minor exception:
- When the front end uses the greatest closure of the context to
implicitly downcast a field from dynamic, it uses a modified
greatest closure algorithm where covariant instances of `_` are
replaced with `dynamic` instead of `Object?`.
The front end's behavior in this rare case doesn't agree with the
spec; I'll address this in a future CL.
Change-Id: Ib1ab7ee4d0f63a152480704e2c0d5332446a613c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350983
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
PR https://github.com/dart-lang/language/pull/3560 and
https://github.com/dart-lang/language/pull/3598 updated the feature
specification of extension types to define a notion of types being
'incompatible with await'. This CL adds a test to verify that various
types are being classified correctly, and errors are hence reported
as expected for expressions of the form `await e`.
Change-Id: I39e992b4317ef49fbc2267819481d71d87b56aca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351143
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
Based on abandoned change #264261.
Changes to that PR: compare and show file paths, improve part parsing, include analyzer expectations from other files as well as CFE expectations, update unit tests.
Add end to end tests. The simplest case "library_failure_test.dart" passes before this PR, all others require the change in this PR to pick up expectations in other files.
Change-Id: Ia71b78a8f0dced83f603309877132f261b47c5a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345541
Reviewed-by: Erik Ernst <eernst@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
There is a performance impact in:
`stdout.lineTerminator = "\r\n";`
For small writes (<100 chars), the performance loss is lost in the noise of the `write` system call.
For writes of ~500 chars, the performance is about half of that without line terminator translation. But, on a M2 Mac laptop, ~80M characters can be written per second.
Bug: https://github.com/dart-lang/sdk/issues/53161
Change-Id: Icfa0f981dcf6edb856d8aac5e0e270bc0148d498
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326761
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Commit-Queue: Brian Quinlan <bquinlan@google.com>
We can't generate a virtual call to `Object.==` in generated code as
`Object.==` may not be added to the dispatch table, even with
`@pragma(wasm:entry-point)`.
Instead this adds a top-level `_runtimeTypeEquals` function that calls
`==` on the `_Type` argument. Effectively this forces adding `_Type.==`
to the dispatch table and calls it virtually.
Fixes#54926.
Change-Id: Ice3306ed00f66c8abedb3ef11b58c15296457eb0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352900
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Users of our standalone embedders we distribute in the Dart SDK should
be using `dart_api_dl.h` (and initialize it from
the `dart:ffi`s `NativeApi.initializeApiDLData`)
If there's any API functions missing, we can add them.
Though we should not Dart C API symbols that are only relevant for
embedders. It requires a custom embedder implementation (which is
outside the scope of what we distribute in Dart SDK)
Issue https://github.com/dart-lang/sdk/issues/40579
TEST=ci
Change-Id: I6f3842668c59a5dd6fefc6857581995501b9b0e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352820
Reviewed-by: Slava Egorov <vegorov@google.com>
Nested macros: check that macro impls can themselves use macros.
Disallowed use: check that macros can't be used in the library in which they are declared, or in the same library cycle.
R=jakemac@google.com
Change-Id: I3b12afc27e5784edc217508b7763a9b448229877
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352522
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
Auto-Submit: Morgan :) <davidmorgan@google.com>
This reverts commit aec3ec0244.
- Corrected 'controlling condition' detection.
- Added test that is incorrectly compiled to infinite loop with incorrect controlling condition detection.
See https://github.com/dart-lang/sdk/issues/54115#issuecomment-1944285230 for an image of part of the CFG for `doWhileLoop` where the condition in B4 was previously mis-identified as controlling `phi(true,false)` at B12.
Issue: #54115
Change-Id: I0d2c2ff83b202071f6d7050d34de8ff25d05cb22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352443
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
- These tests rely on the internals of the old type system.
- Copy some expectations to the language suite when it looks like
there isn't already coverage for the same test.
Change-Id: I63bfa2bc94fb29b4e4f90c3c02cf0943d19764b6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352463
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
This introduces an asyncExpectThrowsWhen to async_helper, similar to
Expect.throwsWhen, to allow specifying semantics under behavior
variations in this test.
We also update await_for_test to no longer skip expectations in dart2js.
Change-Id: Ie147f74f384a0e196e40b75c59fe585f011ede49
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351721
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Today, most tests that touch on a behavior variation end up
skipping expectations or the entirety of a test for some
testing configurations. Moving forward, we'd like skip less
and try to account for the behavior variations if that's
reasonable.
This CL shows an approach to improve our test coverage for
behavior variations. We introduce two new methods to
[Expect] that allow us to conditionally check that a
function throws, depending on variation predicates.
The CL changes expectations for errors that don't occur
when dart2js omits parameter type checks or implicit
downcasts.
Note: originally I had the intention to introduce a name
parameter to `Expect.throws` and `Expect.throwsTypeError` to
avoid introducing a new API. However, because these APIs are
used for testing core language features, such as function
parameters themselves, we decided to keep the use of
features in these APIs as simple as it can be.
CoreLibraryReviewExempt: no public library semantic change - only improving test coverage under variations
Change-Id: I531657622655778491eaca8b37ba69ffaab559fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351340
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
These are tests for the specific apis of the old runtime type system
and they will never pass in the new type system.
Change-Id: I740fc06411cdc621b072782d22ec630c5b6bf96a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341784
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
When a local variable is promoted to a record type, and then an
assignment statement is used to assign a record literal to that local
variable, if the fields of the new record literal are not assignable
to the fields of the promoted record type, that's not a problem; both
the analyzer and front end agree that the local variable is simply
demoted.
But the spec implies that if the old and new record _shapes_ are the
same, then a compile-time error will occur instead of a demotion. I've
created https://github.com/dart-lang/language/pull/3613 to bring the
spec in line with the implementations. This test demonstrates the
current behavior of the implementations, and makes sure that it
doesn't regress.
Change-Id: I0eacd7ca7f6579a35dbc34687113a2112418f368
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/352462
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
