When using `Uri.parse` or `Uri(path:..)`, a `\` is treated as, and converted to, a `/`.
This avoids a particular problematic difference in behavior between Dart and the browser's `URL` functionality. There are still examples where the two differ in interpretation of the same code, but in those cases, the Dart `Uri` will most likely end up without a host name, which should be easily detected.
Change-Id: I798df6c3c27c6d64fb9fc8dc30d90b06ba5a9004
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/258120
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Change-Id: If6ccea08ccd27d0ed001892e2d170ca042b40f47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257062
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
Diagnostic codes which are not in a link do not have a diagnostics page.
Change-Id: Ifedf15e8c956e91a9c498c2496ab9fa3e65844a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256782
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Several unusual constructs that lead to unreachable code are now
recognized by flow analysis:
- Control flow after an expression of the form `e ?? other` or `e ??=
other`, where `e` has static type `Null` and `other` has static type
`Never`, is considered unreachable.
- Control flow predicated on an expression of the form `e is Never`
evaluating to `true` is considered unreachable.
- Control flow predicated on an expression of the form `e is! Never`
evaluating to `false` is considered unreachable.
- Control flow on the RHS of a null-aware access such as
`e?.property...`, `e?.property = ...` or `e?.method(...)`, where `e`
has static type `Null`, is considered unreachable (Note: this can
arise in the presence of extension methods).
Previously, these behaviors only took effect if `e` was a reference to
a local variable.
Note: the change to `regress/issue_31180` is because I’ve corrected
the behavior of implicit temporary variables to not undergo a type
change from `Null` to `dynamic`, so the dead code part of `null?[1]`
is now erroneous. (I had to make this change in order for the last
bullet above to work properly; without it, the type change to
`dynamic` prevents flow analysis from recognizing that the code to the
right of `?.` is unreachable.) There's no behavioral change to
correct code, but I've captured the behavioral change to incorrect
code in
`tests/language_2/null_aware/null_aware_index_on_null_error_test.dart`.
Bug: https://github.com/dart-lang/sdk/issues/49635
Change-Id: I8b24b3b040a34f897c0b61dcb9bd105be6d0af6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251280
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Adds static method on `Isolate` to run an asynchronous function
in a separate isolate.
Change-Id: I673373fa02524f1d0b88099027cfaf1b796eb344
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/254960
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Long ago the compiler had logic for reading sources via an http
connection. This is not a supported use case and there is no need to
keep this around anymore.
Change-Id: Ic59c154def264a52d9310133f76b153c9972899c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251701
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
The `registerElement` APIs in `dart:html` are legacy APIs based on a
deprecated Web Components v0.5 specification. These methods don't work
on modern browsers and can only be used with a polyfill.
The latest Web Components specification is supported indirectly via
JSInterop and doesn't have an explicit API in the `dart:html` library.
This change marks these APIs as deprecated. We intend to remove them in
the future (see https://github.com/dart-lang/sdk/issues/49536)
Fixes https://github.com/dart-lang/sdk/issues/48973
Change-Id: I2e96d36e95c9971b59cde80bc4da49b63d12b17c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252840
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Change-Id: I40d03b47a9f0e4ebe4d3c95d8ab8101a2fd0f7b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/251765
Reviewed-by: Kevin Moore <kevmoo@google.com>
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Because of a problem releasing 2.17.4, a new stable release 2.17.5
is being created with no additional changes. Since 2.17.4 will not
be published, the changelog entry is changed to refer to 2.17.5.
Change-Id: Ibf4c83268790ccca54eb375a3a958dd56ce538d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249189
Reviewed-by: Michael Thomsen <mit@google.com>
There is only one use of it in the SDK, `RuneIterator`,
one use of it outside, `TreeSet` from `package:quiver`,
and one known use in Google internal code.
There are other bi-directional iteration interfaces,
like `CharacterRange` from `package:characters`,
which can move a cursor in two directions,
but which didn't loke the `movePrevious` name and therefore
are not `BidirectionalIterator`s.
(There is also a Google internal class which mentions explicitly
why they're not `BidirectionalIterator`.)
There is no real need for this "shared" interface.
It doesn't carry its own weight.
We have no abstractions which work on the *interface*,
only code that works on one specific concrete implementation.
I'd recommend:
* `quiver` introduce a `TreeSetIterator` for their use-case
(the actual class has more public members than `BidirectionalIterator`,
which cannot be accessed through the declared type.)
* the Google internal code introduces its own interface
(which is just `Iterable` + `movePrevious`.
* The SDK will just make `RuneIterator` not implement
`BidirectionalIterator` at some (breaking) point.
Maybe just when we remove the type.
FLUTTER: Needs to land https://github.com/flutter/flutter/pull/106471 before merging this CL into Flutter.
Change-Id: Iaaa6b0c428d30eb3b68898c077d265ac0a622805
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/249486
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
The current implementation uses a specialized version of the
pending-event queue used by stream subscriptions to remember
pending events.
That makes the queue polymorphic, and slightly more complicated than
necessary, and that again makes further refactorings of the
Stream implementation harder.
This change moves the logic from the specialized pending-queue
into a simple function instead, so you only pay for it if you
actually use `Stream.fromIterable`.
Also allows `Stream.fromIterable` to be listened to more than once.
(It uses `Stream.multi` for the general async+sync controller API,
and it would cost extra code to make it only work once.)
Change-Id: I44b2010225cd3d32c2bcdb8a315c94881331bdae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248146
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Fixes#49241
TEST=ci
Change-Id: I6117bf816fc8c4613cce66927f952fef75632725
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/248120
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This CL remove the support for mixing in classes that don't extend
Object. An error has been report by the analyzer for some time and
now also by the CFE.
This puts the breaking change https://github.com/dart-lang/sdk/issues/48167 into effect.
TEST=pkg/front_end/testcases/general/issue48167.dart
Change-Id: Ia7715a27dc1aa18a7c85b24ed86d19a91b6924d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247551
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This reverts commit abfdc3d50f.
Reason for revert: breaks on internal roll - b/235267735 and others can be fixed in advance of landing this
Original change's description:
> Remove SCREAMING dart:io networking APIs
>
> Bug: https://github.com/dart-lang/sdk/issues/49140
> Change-Id: I50c6cca26597ee4d469b776fcec412ddfed760e1
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246962
> Reviewed-by: Paul Berry <paulberry@google.com>
> Commit-Queue: Michael Thomsen <mit@google.com>
TBR=mit@google.com,paulberry@google.com
Change-Id: I55a43cc1bd7435fe7824f7ca8098575232fdcf2f
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://github.com/dart-lang/sdk/issues/49140
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/247389
Commit-Queue: Oleh Prypin <oprypin@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Oleh Prypin <oprypin@google.com>
Closes#49165
The empty string argument can be confusing to read since it is not clear
what it means. Allow omitting the argument entirely to default to an
empty path.
R=lrn@google.com
Change-Id: I05ca432a679a0df751a16d1beb241b14f80d4681
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/246988
Commit-Queue: Nate Bosch <nbosch@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
This is breaking change #45630.
The Dart VM has until now restored the terminal settings upon exit to
their initial values for stdin, stdout, and stderr. This change removes
that automatic behavior in favor of having the program do the
restoration. Previously the intention was that dart programs can
enable/disable echoing and line buffering and not worry about restoring
the original settings.
However, the VM doing so unconditionally leads to undesirable behavior
e.g. when the program does not care about terminal settings and is
sharing a process group with a program that does care. E.g. if dart's
output is piped into less(1), then there is a race condition where dart
might see the raw terminal settings set by less(1), and if the dart VM
exits after less(1) has exited, then it will restore the raw terminal
settings, leaving the user with a seemingly defective shell with echo
disabled. This race condition can be reproduced using:
cat > yes.dart << EOF
main() {
for (int i = 0; i < 1000000; i++) {
print("yes");
}
}
EOF
stty; (sleep 1 && dart yes.dart) | less; stty; stty sane
The user will end up with a shell with echo behavior disabled. The stty
command shows the current terminal settings, where the difference can be
seen, and 'stty sane' fixes the settings before returning to the shell
prompt. The 'stty sane' call can be omitted to see the defective shell
prompt.
This change removes the terminal restoring behavior (added in Dart
2.0.0) and instead asks applications to do the restoration themselves.
The new design matches how programs in other programming languages
implement interactive input that changes terminal settings.
Furthermore the `echoMode` setting now only controls the `echo` local
mode and no longer sets the `echonl` local mode on POSIX systems (which
controls whether newline are echoed even if the regular echo mode is
disabled). The `echonl` local mode is usually turned off in common shell
environments. Programs that wish to control the `echonl` local mode can
use the new `echoNewlineMode` setting. This change is required to
prevent the reoccurence of #30318 when programs manually restore
`echoMode`.
Windows has further considerations: It also saves the console code pages
and restore them if they were not UTF-8. This behavior is retained as it
is useful and needed for Dart's output to function properly. ANSI output
sequences are also turned on via ENABLE_VIRTUAL_TERMINAL_PROCESSING,
which is slightly changed in this change to only rsetore that setting if
it wasn't already on for consistency.
Closes https://github.com/dart-lang/sdk/issues/36453
Closes https://github.com/dart-lang/sdk/issues/45630
TEST=Reproduced with less as above
Change-Id: I2991f9c7f47b97fe475c1ad6edeb769024f8d0db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/190484
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Alexander Aprelev <aam@google.com>
Reviewed-by: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
