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>
The object graph copy code assumed kImmutableCid is used only for
list constants but it turns out our List.immutable([]) implementation
isn't using a wrapper-view, but instead a fixed-length immutable list as
with constants:
factory List.unmodifiable(Iterable elements) {
final result = new List<E>.from(elements, growable: false);
return makeFixedListUnmodifiable(result);
}
The list constants should already be handled via canonical bit.
Issue https://github.com/dart-lang/sdk/issues/51302
TEST=vm/dart{,_2}/isolates/regress_51302_test
Change-Id: I5924084ff004dc52bf675897455453d728484d1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281421
Reviewed-by: Alexander Aprelev <aam@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Martin Kustermann <kustermann@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>
dartdoc:
494a6bed 2023-02-02 Sam Rawlins Bump markdown dep to a pre-release of 7.0.0 (#3321)
ad6f1612 2023-02-02 Devon Carew introduce an environmentProvider abstraction (#3324)
d0b73000 2023-02-02 Sam Rawlins Prepare testing code for some upcoming Warnings (#3322)
936a7888 2023-02-01 Sam Rawlins Add text about front-end manual testing (#3286)
cbee812d 2023-02-01 Sam Rawlins Avoid renaming generator params (#3316)
bcaa0349 2023-02-01 Sam Rawlins Privatize Library.sdkLib and move getClassByName (#3317)
af32def5 2023-01-31 dependabot[bot] Bump github/codeql-action from 2.1.39 to 2.2.1 (#3313)
528e97da 2023-01-31 dependabot[bot] Bump actions/cache from 3.2.3 to 3.2.4 (#3312)
54020672 2023-02-01 Parker Lougheed Begin changelog for next release after 6.1.5 (#3315)
markdown:
f51c24c 2023-02-01 Zhiguang Chen Prepend a line ending if the p tag is removed and there is an element before it in a *tight* list (#513)
dd3e3a1 2023-01-31 dependabot[bot] Bump dart-lang/setup-dart from 1.3 to 1.4 (#510)
5f25fc9 2023-01-31 dependabot[bot] Bump actions/checkout from 3.2.0 to 3.3.0 (#511)
54266b2 2023-01-31 Kevin Moore Prepare to release v7.0.0 (#509)
d6ceff9 2023-01-31 Zhiguang Chen Add line endings before HTML blocks (#508)
ccd3c8b 2023-01-29 Zhiguang Chen Rewrite link reference definitions (#506)
e8f84dc 2023-01-24 Kevin Moore Update GFM to 0.29.0.gfm.7 (#507)
93f67b0 2023-01-20 Zhiguang Chen Add an `enableTagfilter` option to `HtmlRenderer` to eanble GFM `tagfilter` extension (#447)
d110770 2023-01-13 Zhiguang Chen Rewrite SetextHeaderSyntax (#500)
c1b9bc6 2023-01-09 Sam Rawlins Migrate from no-implicit-casts to strict-casts (#504)
3e78c08 2023-01-01 dependabot[bot] Bump actions/checkout from 3.0.2 to 3.2.0 (#501)
417747f 2022-12-15 Zhiguang Chen Refactor list syntax (#499)
30ec05f 2022-11-29 Zhiguang Chen Do not escape single quote(apostrophe) inside code (#498)
c3d1136 2022-11-29 Zhiguang Chen introduce a Line class (#494)
Change-Id: I9d971b927b72500ab84cce461a60fe1a86818e2e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281543
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Devon Carew <devoncarew@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>
I will be soon be implementing flow analysis for constant patterns.
This test is to ensure that when the language version doesn't include
support for patterns, we reproduce the legacy behaviour of `case null`
(which is not to draw any conclusions about type promotion or
reachability).
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: I2336a0e2cc30f5edf38d2b8da6bcd63fc62b30fd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281282
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This reverts commit 881825980e.
Reason for revert: The Fuchsia build of Flutter engine is broken by this change, since it uses the analyze_snapshot target.
Original change's description:
> [build] Make `build_analyze_snapshot` consistent between the host and target toolchains.
>
> Bug: https://github.com/dart-lang/sdk/issues/51242
> Change-Id: I7a0ad1f0bc94c4593412945e4887f9045693fd40
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/280782
> Reviewed-by: Daco Harkes <dacoharkes@google.com>
> Commit-Queue: Ryan Macnak <rmacnak@google.com>
TBR=rmacnak@google.com,dacoharkes@google.com,dart-scoped@luci-project-accounts.iam.gserviceaccount.com
Change-Id: I3f069274fdef9366fea347ae5f452d2eb2267f70
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: https://github.com/dart-lang/sdk/issues/51242
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/281423
Commit-Queue: William Hesse <whesse@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Auto-Submit: William Hesse <whesse@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>
