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>
Incremental compiler only runs procedure transformations during expression compilation, as opposed to modular library transformations
that are run during initial compilation stage on libraries (including JS interop-related transformations).
In this CL:
- Add implementation of `performTransformationsOnProcedure` to dev compiler target
- runs JS interop-related transformations on a procedure.
- Add related expression evaluation tests
- expressions using JS interop and extension types.
Closes: https://github.com/dart-lang/sdk/issues/53048
Change-Id: I085920db9c3af4c680283c574087d8901c99dfcf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319585
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
While our benchmarks don't involve overlapping memory between source
and destination, general methods for copying between TypedData must.
Thus, our benchmark for using the C interface via FFI must use memmove
instead of memcpy.
To avoid having to update our benchmark configurations, the name of
that benchmark is unchanged.
In addition, this CL adds filtering for benchmark names and turning on
and off specific outputs for quick comparisons when running manually.
Change-Id: I20616549d8bc9ab481884846d3f13df20a3c854e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319981
Commit-Queue: Tess Strickland <sstrickl@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit 58f4b3a7a6.
Reason for revert: Causes build failures in google3 - b/295404395
Original change's description:
> [dart2js] Use symbols for isolate tags
>
> All supported browsers have JavaScript Symbols so use Symbols.
> Avoiding string property names should fix a bug where separate
> programs running in separate iframes arrive at using the same
> property.
>
> Issue: #53154
> Change-Id: I470dc47de3ad381aeab670cf62d62e53f2e72873
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319865
> Reviewed-by: Sigmund Cherem <sigmund@google.com>
> Commit-Queue: Stephen Adams <sra@google.com>
Issue: #53154
Change-Id: I581fe08aee6ac9e2d74e813641a942223553cf5d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319980
Auto-Submit: Oleh Prypin <oprypin@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Oleh Prypin <oprypin@google.com>
Adds special representations of runtime types for the interface types
`Object`, `Function` and `Record`. With this change, all types with
non-interface subtypes have special representations, which avoids some
special cases down the line.
Change-Id: I61b4da20fa1cc62d42e1770278a3272028c9e2a0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/318681
Reviewed-by: Joshua Litt <joshualitt@google.com>
All supported browsers have JavaScript Symbols so use Symbols.
Avoiding string property names should fix a bug where separate
programs running in separate iframes arrive at using the same
property.
Issue: #53154
Change-Id: I470dc47de3ad381aeab670cf62d62e53f2e72873
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319865
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
No longer marks a few error codes as unverified if the issue no longer exists or an adjustment of the offset/length was needed.
Change-Id: I78aa557dcffeafb5c3af40b978fa23ba0bc93a0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319640
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
1. It is not allowed to write a nullable type in `implements`.
2. Any methods of the extension type itself are OK to invoke.
I start to doubt what is the meaning of isNonNullable() to extension types.
For now I will add a workaround, to be reconsidered if isNonNullable() is
clarified.
Change-Id: I8a9543a6b0e942ae4de3ce673eeee1aa9b0a5230
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319862
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
With this change the Dart Core Object members (`.hashCode`,
`.runtimeType`, `.noSuchMethod()`, `.toString()`, and
`operator ==`) are no longer installed onto the native JavaScript
Object prototype. This is done because the Object prototype will be
sealed as a security precaution in some environments to avoid
prototype pollution exploits.
This means that dispatching to these APIs will change when the
compiler cannot know if the receiver may be null or a value from
JavaScript interop. In those cases a call to a helper method is
inserted instead. The helpers will probe for the API on the value,
call it if available or execute a default version.
NOTE: Many other native JavaScript prototypes are still modified. This
change is only for the Object prototype.
Issue: https://github.com/dart-lang/sdk/issues/49670
Change-Id: Iddb3a48e790dd414aa3254d729535c4408e99b3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/310971
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
This test was writing a package_config after starting the analysis server which causes the context roots to be rebuilt (during which there is a period when there are no roots/drivers), and then not waiting.
This change creates the file before server initialisation.
Change-Id: Id0111f16200a905dd538e217199133122be84246
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319801
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This is a non-functional refactor that extracts the growing set of capabilities and options from ServerCapabilitiesComputer into files alongside the handlers they relate to.
The motivation for this is that for LSP-over-Legacy we'll need to accept client capabilities (and return server capabilities). The server capabilities will be different to the standard LSP ones (they will be a subset, and we might not support dynamic registration - at least initially). However the features we do support will have the same registration options, so to avoid duplicating them this moves the registration options away from the creation of the ServerCapabilities.
In future, we might consider further wrapping up a "feature" (which consists of these registration options, and the related handlers), but this change is already quite large and I just wanted to progress capabilities for LSP-over-Legacy so we can handle things like Code Actions (which require executeCommand and possible reverse-requests for applyEdit).
Change-Id: Iecd0aa36626fa44826f7d4dbd6e6c0d758075239
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319840
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The interceptors provide a Dart `toString` method that uses the JavaScript `toString` method.
Issue: #53106
Change-Id: I1cf1df9e24fb4fd2d79679f1f014f39f083be7e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319563
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
This reverts be4189f047 plus adds an additional test to verify pkg:path to behaviour (to catch future regressions or if pkg:path has to be reverted, this will need reverting too).
This relies on the fix made at https://github.com/dart-lang/path/issues/148 which rolled into the SDK in f1de897762.
Change-Id: I1dea45e2017f7505bc4aca97f6c07c1a6e445a5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/319523
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
