Use `hasScheme` in place of comparing against the empty string, and
`isScheme` to compare against all other schemes.
TEST=No behavior changes.
Change-Id: Ifc9fd13c6cf37933ebd4a754c4b500dedbcb291b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/231185
Reviewed-by: Kevin Moore <kevmoo@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
strict-casts is mostly a drop-in replacement for the deprecated
`implicit-casts: false` option. One big difference, seen in this CL, is that
strict-casts will report a non-Iterable (or non-Stream) in a for-each loop.
Change-Id: Ibc463ae9c870b6a795483c5dea0d2b856e7fd883
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/221546
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
In the test suite, the options passed to the two phases of the
compile drifted apart. Some were false when compiling the module
but true when printing that module as Javascript. This surfaced
when some unused portions were migrated to null safety.
Change-Id: I2d5c648bc53e5c9fe3f014446393d0f893bd5382
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/218181
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Most of these arguments are flowing through to a `--packages` argument
which allows passing the `package_config.json` file. In the long term we
should remove the `.packages` file entirely.
TEST=None, the change should have no visible impact.
Change-Id: I60a8b175d5e217a85588bbcb91cc5095514066b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/211503
Auto-Submit: Nate Bosch <nbosch@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Lasse R.H. Nielsen <lrn@google.com>
* Tests constructor tear off values and calling torn off constructors.
* Covers default, named, redirecting, and factory constructors at break
point locations in a method, global function, and inside the default
constructor.
* Create new test suites for legacy code (Dart language version 2.11)
in amd and ddc module systems.
* Sound and Unsound suites now run code without a Dart language comment.
Change-Id: I9cf16c258ce6ece7c436f9deb044ed821f980d1b
Fixes: https://github.com/dart-lang/sdk/issues/47214
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/214866
Reviewed-by: Anna Gringauze <annagrin@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
This CL removes async markers where await wasn't used.
In a few cases this also meant the ability to make the procedure not
return a future at all.
Also - at least on the VM with my benchmark run on my PC - returning
new Future.value(whatever) in a non-async procedure is faster than
returning whatever in an async procedure.
TEST=CI and existing tests.
Change-Id: I4ba888313c87de76bb0ca02c19eb1ab45f168a85
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/213480
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
* Update tearoff runtime equality algorithm with newly specified
requirements.
* Update kernel golden files for the dartdevc target to include
the static method lowering for constructor tearoffs.
* Avoid adding source maps and debug symbols to the static methods
created by the CFE lowering.
* Add additional expected non-nullable values detected in the
nullable inference tests. These correspond to the values that
appear in the static method return statements.
Measurements taken from large applications show the lowering causes
a code size increase of 2.5%-3.5%. That increase did not appear to
create any measurable difference in initial page load time but if
there turns out to be a regression we can revisit each of the various
lowerings to implement support in DDC at the site where the constructor
is torn off.
Fixes: https://github.com/dart-lang/sdk/issues/46486
Fixes: https://github.com/dart-lang/sdk/issues/46837
Change-Id: I01fa39d4f1d0e937919dd1466bb6a34c91a10e75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206960
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
We use `package:shelf/shelf_io.dart` to serve the requests,
which in turn uses `package:shelf_proxy/shelf_proxy.dart` as
an inner request handler.
On exception (such as seen in the webdev CI failures) the shelf_io
returns 500 response, which is currently is not causing a retry in
RetryTimeoutClient.
This change adds retries on 500.
Add tests with server returning InternalServerError.
Closes: https://github.com/dart-lang/webdev/issues/1345
Change-Id: I73470d73fb5651edee4bf2033ae514930bfe28c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/206581
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Kevin Moore <kevmoo@google.com>
Recent flakes in webdev CI show failures to load dill files
due to broken sockets (most likely caused by connection timeouts).
This change adds retries and timeouts to the asset server file
system to make it tolerant to breaking connections.
- Add RetryTimeoutClient wrapper for HttpClient that performs
retries with delays and connection/response timeouts, based
on the idea in
https://github.com/dart-lang/http/blob/master/lib/retry.dart
- Make AssetFileSystem use the RetryTimeoutClient.
- Add tests for reading multiple files concurrently.
- Add tests for ExpressionCompilerWorker reading assets using
standard, multiroot, and asset file systems.
- Simplify uri that AssetFileSystem uses to query the asset
server, since we no longer need to load package uris.
This will eliminate a step in uri translation in dwds.
- Validated that changes do not break google3 manually.
Change-Id: I2ff163b8d99cd0b7551f3f33a71e6b306540e3c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204880
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Adding explicit source maps to the operator created a breakable location
when viewing source-mapped dart code in chrome devtools. There isn't a
breakable point in the javascript for a `!` operator so trying to enable
the breakpoint visible in the dart code would trigger some "other
breakpoint".
Recent changes in the V8 debugger have changed which "other breakpoint"
would be triggered.
https://chromium.googlesource.com/v8/v8/+/16b0767adc54de6e0154a0a8226e01efecfdbfbb
This causes our tests to fail and makes the user
interaction a little confusing. Removing the extra source map here seems
to be the most reasonable solution because it prevents a possible
breakpoint from appearing where there isn't a breakable location.
Now, the ! operator doesn't introduce any new source mapping it simply
continues the previous mapping.
Change-Id: I5903bfeaf1bcb2e2a3ce883433153575aa1fd05a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/204742
Reviewed-by: Mark Zhou <markzipan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
We are seeing CI flakes in webdev when using expression_compiler_worker
in tests involving expression evaluation, for example, see linux tests
for dwds in the following PR:
https://github.com/dart-lang/webdev/pull/1343
The logs show that HttpFileSystemEntity.exists fails due to a broken
pipe, which we suspect is due to http client closed too early.
This change is an attempt to fix the problem by
- logging exceptions thrown in expression compiler worker
- awaiting for the request to be read before closing http client in
HttpFileSystemEntity.
TEST=pkg/dev_compiler/test/expression_compiler/asset_file_system_test.dart
See investigation of the CI issue in:
https://github.com/dart-lang/webdev/issues/1345
Closes: https://github.com/dart-lang/sdk/issues/46388
Change-Id: Iaf98f08e8ebb618bf8365bd497f01ae685f0d3f2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/203841
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>