There are a couple of small format changes, but they are minimal
enough that we might not need to land a pre-built SDK with this.
Change-Id: I1d258c8a782e5db24c2048f407a8b7cf7b948eef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325580
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
This reverts commit 2a669c571f.
Reason for revert: Failing dart -> Flutter Engine roller. We need to make some changes on the engine side to prepare for re-enabling these checks.
Original change's description:
> [dart:js_interop] Re-enable type checks on external APIs
>
> External APIs when using dart:js_interop should only allow
> primitives, JS types, and other static interop types. This
> was previously checked in a more restrictive mode called
> "strict mode" but is not checked everywhere where dart:js_interop
> APIs exist.
>
> Change-Id: Ic82a3ec0bf6062c25d7f8933e503820a21bc191f
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316867
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: I54caf06976e215b2b576cedfc0013ee79c6682f6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/324902
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
External APIs when using dart:js_interop should only allow
primitives, JS types, and other static interop types. This
was previously checked in a more restrictive mode called
"strict mode" but is not checked everywhere where dart:js_interop
APIs exist.
Change-Id: Ic82a3ec0bf6062c25d7f8933e503820a21bc191f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316867
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Adds JSSymbol and JSBigInt and erases to either their respective
interceptor types in the JS backends or JSValue in dart2wasm.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: Ib2c70d22a70c6308733cd170b91eafa8ec3b3aeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321749
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Adds the same interceptors from dart2js as JsPeerInterfaces
and handles typeof differences in getReifiedType. These must
be JsPeerInterfaces so that Object members can be stored in
their prototype. Tests are added so that dart2js and ddc are
consistent.
Change-Id: Iadc3dd26957c0a21b4039c49c1c1ff162ae286e6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321748
Reviewed-by: Stephen Adams <sra@google.com>
Fix allowed it to accept null but it should never be called with a
nullable value.
Change-Id: I03b5d9b4906e9e4557a4f2720350c0c8176fec53
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320841
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Nicholas Shahan <nshahan@google.com>
The underlying subscription would invoke the `onDone` handler even
after a `cancel`.
It also forgot to register the `onDone` callback in the zone before
running it.
Tweaked the behavior of `pause` and `resume` to make sure they make
no difference after `cancel` or after a done event has been omitted.
(Test now checks that the behavior matches other streams.)
Fixes#53201
Bug: https://dartbug.com/53201
Change-Id: Iba35be2c4b44b5c4ec97d5a4dbcd3aff7fee8b75
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320561
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
This is likely more useful than returning globalThis always. It
allows users to workaround issues with lowerings without having
to worry about browser compatibility differences.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I01479211fe6b573c845de5b134d36338c40fc10d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319301
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Fixes https://github.com/dart-lang/sdk/issues/52955
Instead of globalThis, dart2js and DDC will now use the same global
context that they did for non-static interop. dart2wasm will
continue to use globalThis.
Change-Id: Iec899fc73ed35c50cd688d9b45b980e94f101c0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318520
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
- Updates a few broken links
- Fixes a few spelling mistakes
- Standardizes formatting in recent entries
- Provides a few more details where helpful
Change-Id: I8d5376dfe2dec11b53cb38081f0e268c3cee51ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320140
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Previously, the flow control logic for patterns didn't use the
`FlowModel.split` or `FlowModel.unsplit` methods at all. This meant
that if a control flow join point occurred in pattern logic, flow
analysis would consider the split point to be whatever split point was
established by the enclosing expression or statement. In the case of
an if-case statement, it would consider the split point to be at the
beginning of the scrutinee expression.
Split points are used by flow analysis for the sole purpose of
ensuring that joins propagate type promotions the same way in dead
code as they do in live code (so that users introducing temporary
`throw` expressions or `return` statements into their code do not have
to deal with nuisance compile errors in the (now dead) code that
follows. The consequence of flow analysis considering the split point
to be at the beginning of the scrutinee expression is that if the
scrutinee expression is proven to always throw, then joins that arise
from the pattern or guard may not behave consistently with how they
would have behaved otherwise. For example:
int getInt(Object o) => ...;
void consumeInt(int i) { ... }
test(int? i) {
if (
// (1)
getInt('foo')
case
// (2)
int()
// (3)
when i == null) {
} else {
// (4)
consumeInt(i);
}
}
In the above code, there is a join point at (4), joining control flows
from (a) the situation where the pattern `int()` failed to match, and
(b) the situation where `i == null` evaluated to `false` (and hence
`i` is promoted to non-nullable `int`). Since the return type of
`getInt` is `int`, it's impossible for the pattern `int()` to fail, so
at the join point, control flow path (a) is considered
unreacable. Therefore the promotion from control flow path (b) is
kept, and so the call to `consumeInt` is valid.
In order to decide whether to preserve promotions from one of the
control flow paths leading up to a join, flow analysis only considers
reachability relative to the corresponding split point. Prior to this
change, the split point in question occurred at (1), so if the
expression `getInt('foo')` had been replaced with `getInt(throw
UnimplementedError())`, flow analysis would have considered both
control flow paths (a) and (b) to be unreachable relative to the split
point, so it would not have preserved the promotion from (b), and
there would have been a compile time error in the (now dead) call to
`consumeInt`.
This change moves the split point from (1) to (2), so that changing
`getInt('foo')` to `getInt(throw UnimplementedError())` no longer
causes any change in type promotion behavior.
The implementation of this change is to add calls to `FlowModel.split`
and `FlowModel.unsplit` around all top-level patterns. At first glance
this might appear to affect the behavior of all patterns, but actually
the only user-visible effect is on patterns in if-case statements,
because:
- In switch statements and switch expressions, there is already a
split point before each case.
- In irrefutable patterns, there is no user-visible effect, because
irrefutable patterns cannot fail to match, and therefore don't do
any control flow joins.
This change allows the split points for patterns to be determined by a
simple syntactic rule, which will facilitate some refactoring of split
points that I am currently working on.
Change-Id: I55573ba5c28b2f2e6bba8731f9e3b02613b6beb2
Bug: https://github.com/dart-lang/sdk/issues/53167
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319381
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Since user @staticInterop types are erased to JavaScriptObject, they
should only be able to subtype other types that are :> JavaScriptObject,
which are just JSObject and JSAny. Eventually all the other JS types
will move to extension types and we can remove this check.
Change-Id: If56b6770e141238b583937880ca87496780c8fac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316865
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Since external APIs can only use primitives and JS types in static interop,
we should require that all type parameters on static interop APIs extend
another static interop type. This is the minimum required to ensure all
type parameters can be erased to JSValue. This only affects dart:js_interop
users and replaces the previous type parameter static error check.
Change-Id: Ia546874da73c808aa25deb8d54d581db783987df
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/316140
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This is a reland of commit 16fcfe7eae
Original change's description:
> [dart:js_interop] Remove Object.toJS and JSNumber.toDart
>
> Modifies JSBoxedDartObject reified type on JS backends and also
> modifies JSBoxedDartObject.toDart now that a proper box is introduced.
> Also uses a JS symbol in JSBoxedDartObject.toDart for a property
> check so that different Dart apps don't accidentally share Dart
> objects. It's now an error to call this function on non-boxed objects.
>
> Fixes a type issue where creating a new object literal with the JS
> foreign function was resulting in dart2js thinking toJSBox would
> always throw. Changing the typeDescription to PlainJavaScriptObject
> instead of =Object fixes that issue.
>
> CoreLibraryReviewExempt: Backend-specific library.
> Change-Id: I5cfb1f32ff4328fafdf9831b0d8da806c39391d9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309082
> Reviewed-by: Joshua Litt <joshualitt@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
CoreLibraryReviewExempt: Reland.
Change-Id: If6b190f12bdf840b0259c5739f50d9bdcd27fd47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313600
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This reverts commit 16fcfe7eae.
Reason for revert: Flutter changes haven't landed to google3 yet.
Original change's description:
> [dart:js_interop] Remove Object.toJS and JSNumber.toDart
>
> Modifies JSBoxedDartObject reified type on JS backends and also
> modifies JSBoxedDartObject.toDart now that a proper box is introduced.
> Also uses a JS symbol in JSBoxedDartObject.toDart for a property
> check so that different Dart apps don't accidentally share Dart
> objects. It's now an error to call this function on non-boxed objects.
>
> Fixes a type issue where creating a new object literal with the JS
> foreign function was resulting in dart2js thinking toJSBox would
> always throw. Changing the typeDescription to PlainJavaScriptObject
> instead of =Object fixes that issue.
>
> CoreLibraryReviewExempt: Backend-specific library.
> Change-Id: I5cfb1f32ff4328fafdf9831b0d8da806c39391d9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309082
> Reviewed-by: Joshua Litt <joshualitt@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: I469ad04db7b49ffef47a46ccac97e909e4865719
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/313580
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Modifies JSBoxedDartObject reified type on JS backends and also
modifies JSBoxedDartObject.toDart now that a proper box is introduced.
Also uses a JS symbol in JSBoxedDartObject.toDart for a property
check so that different Dart apps don't accidentally share Dart
objects. It's now an error to call this function on non-boxed objects.
Fixes a type issue where creating a new object literal with the JS
foreign function was resulting in dart2js thinking toJSBox would
always throw. Changing the typeDescription to PlainJavaScriptObject
instead of =Object fixes that issue.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I5cfb1f32ff4328fafdf9831b0d8da806c39391d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309082
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This reverts commit a356f71b71.
Reason for revert: This should be handled by throwing an exception when
the methods of the returned window are called, not when it is opened.
This would be a noisy breaking change that we don't want for 3.1. For
now, revert until the change that affects the individual methods is
landed.
Original change's description:
> [dart:html] Throw exception if Window.open opens null window
>
> Window.open silently allows a null window to be opened, and
> issues arise later when users try to use the non-null wrapper.
> This CL changes that to throw an exception if the window is null.
> This exception can be caught and recovered from. This avoids the
> larger breaking change of making this API nullable.
>
> CoreLibraryReviewExempt: Backend-specific library.
> Change-Id: I9a53a477cb370c3bc6bc26b2162ce66c5af166aa
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306910
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
CoreLibraryReviewExempt: Revert in backend-specific library.
Change-Id: I5007b7d7aa608bfc8e5827b5f967af5573d0b758
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/309000
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This reverts commit 14a3051552.
Reason for revert: b/289195983
Original change's description:
> [dart:html] Move NullWindowException to implementation
>
> Window.open may open a null window in more cases than expected.
> Users may not care that the window they get back is invalid if
> they never use it. Therefore, this CL moves the exception to
> the implementation of the returned window in order to reduce
> noise, but still give a way for users to recover if they wish
> to do so.
>
> CoreLibraryReviewExempt: Backend-specific library.
> Change-Id: I005cf80630cfb4db2f5ec2012cfcd0161ad10ff1
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311460
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
Change-Id: Id7c514a80fdcaa18a7eb0acdcb7f36477a04d966
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311843
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Ivan Inozemtsev <iinozemtsev@google.com>
Window.open may open a null window in more cases than expected.
Users may not care that the window they get back is invalid if
they never use it. Therefore, this CL moves the exception to
the implementation of the returned window in order to reduce
noise, but still give a way for users to recover if they wish
to do so.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I005cf80630cfb4db2f5ec2012cfcd0161ad10ff1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/311460
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Window.open silently allows a null window to be opened, and
issues arise later when users try to use the non-null wrapper.
This CL changes that to throw an exception if the window is null.
This exception can be caught and recovered from. This avoids the
larger breaking change of making this API nullable.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I9a53a477cb370c3bc6bc26b2162ce66c5af166aa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306910
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This annotation is unneeded as named arg external constructors
is enough to determine if an object literal is created. The one
exception is an empty object literal, but our guidance is to use
utility functions to create one instead. This is a better fit for
that purpose too as an interface for an empty object literal is
more uncommon.
CoreLibraryReviewExempt: Backend-specific library.
Change-Id: I10cf891601b28ff7e56129842d099ea28863626d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/307506
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This includes a single commit which fixes:
https://github.com/dart-lang/dart_style/issues/1224
This doesn't need to be coordinated with a pre-built SDK update.
Change-Id: Ifaabfde1d0d3dc180cf65a1052ba8dcff3324013
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/306122
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Breaking change request: https://dartbug.com/52334
Four abstract pure-interface classes in `stream.dart` have
been missed, and not made into `interface` declarations
like other similar abstract interface-only classes.
They should be marked `interface`, for consistency,
and to express intent.
The classes are:
* `StreamConsumer`
* `StreamIterator`
* `StreamTransformer`
* `MultiStreamController`
All are abstract classes with only abstract instance members.
Only `StreamConsumer` has uses where it is extended.
Most of those are inside the SDK, and are fixed here.
Two more are in packages (`http_server` and `streams`).
The former is discontinued and archived, and will never have a 3.0
release. The latter is internally developed and easy to fix.
Hope to cherry pick this for 3.0.3
Tested: Modified affected tests. Only adding restrictions.
CoreLibraryReviewExempt: Adding modifiers only.
Change-Id: I41aa47e48eaf769b7bd9d3206c1079a16ef3d476
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/302204
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
