Rest patterns in maps are represented with a special distinguished
MapEntry that otherwise looks like `null: null`. In the callback
methods `isRestPatternElement`, `getRestPatternElementPattern`,
`handleMapPatternRestElement`, and `getMapPatternEntry` we need to
recognize this MapEntry and treat it specially.
This will pave the way for integrating constant pattern handling
between the front end and shared logic. (If we tried to integrate
constant pattern handling without doing this fix first, then map
patterns containing `...` would be retreated as though they contained
`null: null`, and hence they wouldn't be usable in irrefutable
contexts.)
Change-Id: Idcad97af6de49f3363fc777f54d5b6205bebf19d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281520
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This implements this part of the language spec (section 17.10):
> If v is an instance of class Error or a subclass thereof, and it is
> the first time that Error object is thrown, the stack trace t is
> stored on v so that it will be returned by the stackTrace getter
> inherited from Error.
New passing tests:
- co19/Language/Expressions/Throw/stack_trace_t01
- co19/LibTest/core/Error/stackTrace_A01_t01
- co19/LibTest/core/IndexError/stackTrace_A01_t01
- corelib/error_stack_trace_test/none
- corelib/error_stack_trace_test/nullThrown
- language/stack_trace/error_runtime_test
Fixes#50608
Change-Id: I1d7df2337cce1be3ecbab0180def5769b8fe3e68
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279966
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Revert submission 279511
Reason for revert: Flutter dependencies are using nullable struct
fields and need to be migrated first
https://github.com/flutter/flutter/issues/120260
Reverted changes: /q/submissionid:279510 /q/submissionid:279511
Change-Id: I84d8ec03bc56e4cf9d18ae99954c89ae61eb233a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281601
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Revert submission 279511
Reason for revert: Flutter dependencies are using nullable struct
fields and need to be migrated first
https://github.com/flutter/flutter/issues/120260
Reverted changes: /q/submissionid:279510 /q/submissionid:279511
Change-Id: I7ab66ef6c6b5f21303804b2930af4ad6aa000413
Tested: Revert
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281600
Reviewed-by: Johnni Winther <johnniwinther@google.com>
'Annotations' allow client information to be attached to js_ast nodes.
I will be using this facility to embed resource identifers in the generated JavaScript AST to generate a map from files to the resource identifiers that they contain.
Change-Id: Id9012b303de0d2b3848a635bc34747f8c5101236
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281320
Reviewed-by: Nate Biggs <natebiggs@google.com>
Commit-Queue: Stephen Adams <sra@google.com>
There are two new API methods: `equalityRelationalPattern_end` (for
relational patterns using `==` or `!=`, where some degree of flow
analysis is warranted) and `nonEqualityRelationalPattern_end` (for all
other relational patterns, where all we care about is making sure that
both the "matched" and "unmatched" branches are reachable).
I've moved most of the logic for constant patterns into
`equalityRelationalPattern_end`, since it's essentially the same logic
(except that `equalityRelationalPattern_end` also has support for
`!=`). So now, `constantPattern_end` simply calls
`equalityRelationalPattern_end` in the case where pattern support is
enabled.
I also had to make a change to `RelationalOperatorResolution` to make
it possible to distinguish `==` from `!=`.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: Idc5dbcfb02e3f8b57cfcccb3f46364fe34268ded
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280900
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Some notes.
* There are a number of tests that should get decoupled from the linter being pulled into `DEPS`. Instead of depending on the state of lints there, we should update the tests instead to use a more hermetic environment. (See for example `options_rule_validator_test.dart` for how that might look.)
Downstream (blocking) fixes:
* https://github.com/flutter/flutter/pull/119736
* https://github.com/flutter/gallery/pull/878
Change-Id: I5671b0abde3eeda75513abaaf9fef3bcd5115f9b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280054
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Use `AddConstant` or `RemoveConst` instead
Fixes#50803
Change-Id: Idf0b2f626558a8b2abb91eb0a4c4872f91e29632
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277120
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
We now attempt to evaluate
- final local variables with initializers
- final statics with initializers
- static or local function invocations if they just return an expression
by attempting to const-evaluate the initializer/returned expression.
Change-Id: I976863d950ba1609c5d8e6a21884ca56af0d2b4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/275145
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Mayank Patke <fishythefish@google.com>
Suppose we have code like
if (isDevMode) {
// do foo
} else {
// do bar
}
where isDevMode is const (or can be evaluated as const). In particular,
isDevMode can be controlled by compile-time options, like
bool.fromEnvironment.
We currently eliminate the dead branch during SSA, but that means we do
the work of compiling dead code in the previous phases. Instead, we can
recognize that the condition is const (or effectively const) and
eliminate the dead AST subtree directly.
Change-Id: Ia91da5ebc7fa496a1b963308c6e02d572cab936e
Bug: b/254543452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/270281
Reviewed-by: Sigmund Cherem <sigmund@google.com>
There are a few places in our runtime libraries where we have some code
guarded by `if (false)`. This is to ensure that the guarded code is
marked as used and compiled, but not emitted unless rewritten during
SSA. This pattern is somewhat brittle - a kernel
optimization/transformation which eliminates dead code may discard the
code.
Instead, we can write `if (JS_GET_FLAG('FALSE'))`, which will only be
written to `if (false)` and then discarded during SSA.
Change-Id: I8edc2b24e5fbeece1f042ff3d0c87d58e939bf84
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/271800
Reviewed-by: Stephen Adams <sra@google.com>
Amends lowerings on dart2wasm and JS backends to work for external
constructors/factories and static members. Tests members with and
without renaming of members/classes/libraries. Note that this does
not add support for object literal factories yet.
Change-Id: I149bef7249c1a13a31eed9f3510256d407b1d3e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280056
Reviewed-by: Joshua Litt <joshualitt@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
TEST=dart2wasm no longer crashes on inline classes
InlineTypes can be treated as their underlying representation
types instead.
Change-Id: I802de0112f3f62024bc746e30b3db90506a0e159
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280620
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
This is mostly to get the test bots running for tests that use
inline classes. It's possible there are other visitors that need
to be modified that this CL does not touch.
Change-Id: I9359f41a8dd51c290304126510122cc565902d98
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280402
Reviewed-by: Stephen Adams <sra@google.com>
Since matching a constant pattern implicitly performs an equality
check, we do the same flow analysis for constant patterns that we
would have done for an explicit equality test. There are only two
user-visible behaviours:
- If the constant pattern is a `null` literal, then in the code path
where the pattern fails to match, the scrutinee is promoted to a
non-nullable.
- If the constant pattern and the scrutinee are both `null` literals,
the pattern match is known to always succeed (so the code path where
the pattern fails to match is marked as unreachable).
The first of these two behaviours is genuine useful to the user, since
it allows things like:
switch (expr) {
case null:
...
...
default:
// expr is known to be non-`null`.
}
The second behaviour is not so useful, but seemed worth doing to
maximize code sharing and to keep the behaviour consistent between
pattern matching and explicit null checks.
Making this work required extracting some of the logic that was
formerly in `_FlowAnalysisImpl.equalityOperation_end` into a method
`_equalityCheck`, which understands how to analyze an equality check
regardless of whether it's an explicit equality expression or an
implicit part of a pattern. It returns an `_EqualityCheckResult`,
which `equalityOperation_end` examines to determine exactly what needs
to be done to for an equality test in an expression context;
similarly, `_FlowAnalysisImpl.constantPattern_end` now calls
`_equalityCheck` and then does the right thing for patterns.
It was also necessary to extract the logic from
`nullCheckOrAssertPattern_begin` for handling null checks in patterns;
that logic is now in `_nullCheckPattern`, which is also called by
`constantPattern_end`.
In the process of testing this change, I discovered (and fixed) a
minor bug: when analyzing a switch statement or switch expression, we
were re-capturing the value of the scrutinee before visiting each
pattern. This meant, for example, that we would analyze the following
code incorrectly:
int? i = ...;
switch (i) {
case _ when f(i = ...):
...
case null:
...
default:
// `i` should *not* be promoted to non-null here, because it's
// not guaranteed to be the same as the value matched by `case
// null` above.
}
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: I4d30d6bc2673d9968e69f3384a37e1b2b9cc4a8f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280861
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This will make it possible to generalize the flow analysis logic we
already have for equality expressions and calls to `identical`, so
that we can use it for constant patterns (which implicitly do an
equality check) and relational patterns involving `==` or `!=`.
This requires adding a new method to the flow analysis API,
`FlowAnalysis.assignedVariablePattern`, to handle variable references
appearing inside a pattern assignment. Previously we were able to use
`FlowAnalysis.write` for this purpose, relying on its call to
`getExpressionInfo` to gather the relevant information about the RHS
of the assignment. But now, since we are calling
`equalityOperand_end` from `_pushScrutinee`, the expression info is no
longer available at the time we visit the variable reference.
Change-Id: I9a28bced97dcf6ee15674eaa4430910121185489
Bug: https://github.com/dart-lang/sdk/issues/50419
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280219
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When named argument are used before positional, front-end can insert
additional temporary variables in order to keep original evaluation
order. As a result, List factory specialization was not able to
match constant arguments such as 'growable: false' in the AST.
This change fixes this problem by adding extra unwrapping of final
variables before matching constant arguments during list factory
specialization.
TEST=pkg/vm/testcases/transformations/type_flow/transformer/lists.dart
Fixes https://github.com/dart-lang/sdk/issues/51252
Change-Id: If69789ba15aed28a3c1f137a09b3b77f719f437e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281240
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Auto-Submit: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
The named parameter `isExhaustive` was renamed to `isLegacyExhaustive`
in https://dart-review.googlesource.com/c/sdk/+/274720, but the error
messages that result from not using it properly were not updated.
This change updates the error messages to reduce confusion when
writing tests.
Change-Id: I20664ef53b0e0e758f2d43d52d5d1747e4c499f0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280660
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Before this CL, typing in a big file in IntelliJ on Windows could lead
to longer and longer latency (read: taking longer and longer from you're
finished writing and the code is error free until the editor doesn't
report an error --- I've reached 40 seconds for a simple print statement
in my testing).
This is caused by a number of things; this CL fixes the issue by
receiving data from stdin in an isolate.
Background:
* The IntelliJ plugin sends the whole file on every change in a file.
Files can be big though, and e.g. `ast.dart` in the kernel package is
almost 500 kb.
* The IntelliJ plugin sends the data in chunks of size ~8192 bytes.
* On Windows (but not Linux) it is also received in chunks of that size.
* Darts `LineSplitter` is currently quadratic in behavior
(https://github.com/dart-lang/sdk/issues/51167) (to be fixed with
https://dart-review.googlesource.com/c/sdk/+/280100)
Even with the fix of `LineSplitter`, when editing `ast.dart` in IntelliJ
on Windows, (as long as one is typing fast enough) we'll create a longer
and longer queue of messages (with more and more latency).
In testing I reached ~40 seconds of latency, i.e. after I was done
typing and there were no more errors it took ~40 seconds before the
Analyzer and the editor agreed.
I think what's happening is something like this:
* You type a character in IntelliJ in Windows.
* IntelliJ sends two requests: Updated content (the whole file, i.e.
lots of data) and "give me completions".
* You type another character (I seem to type one character every ~150 ms
when typing) and it sends two new requests.
* When receiving is slow it processes everything. So it updates the file
and marks the file for being analyzed. Then it processes the
completion requests which "forces" the file to be analyzed. This takes
more than 150 ms, so it gets behind. More and more so for each
character typed.
Receiving in an isolate means that once the main thread receives
(now via a `ReceivePort`) it receives more data and can now skip some of
the completion requests meaning that it doesn't analyze the file for the
"intermittent" updates.
Change-Id: I43507412abfddcfb903d90d86226172b291bdb47
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280321
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Use explicit ddc-options to pass `--canary` flag to the compiler instead
of sniffing for a builder tag.
This just feels more expected and makes more sense if you are trying
to understand how the canary configurations compile tests differently
from the stable configurations.
Change-Id: I59b1e62d3839f6f992eea917ecbae240640fcd76
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280783
Commit-Queue: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
When seing a '(' after a var/final in `parseVariablePattern` require a
type --- the only allowed thing is a record type, but we can't
generally allow for instance `() async =>` as a record type as that
normally means something else.
Fixes#51230
Bug: https://github.com/dart-lang/sdk/issues/51230
Change-Id: I2e4797595b545d4cb726e36ce4e70a4d775e7e25
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280720
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
