Could for instance be run like this:
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --candidates=cfe_compile_trace_candidates.txt
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
out/ReleaseX64/dart pkg/front_end/tool/flame/instrumenter.dart pkg/front_end/tool/_fasta/compile.dart --candidates=cfe_compile_trace_candidates_subsequent.txt
out/ReleaseX64/dart pkg/front_end/tool/_fasta/compile.dart.dill.instrumented.dill --omit-platform pkg/front_end/tool/_fasta/compile.dart
* The first command compiles and instruments "compile.dart" to record
all procedure calls.
* The second command runs the instrumented compiler on "compile.dart"
(but it could have compiled anything). Because every procedure is
instrumented this will take a lot longer than a usual run.
This produces a trace "cfe_compile_trace.txt" with every call taking
at least 1000 microseconds. This can be displayed via Chromes
about://tracing tool.
It also produces a file "cfe_compile_trace_candidates.txt" with a map
of the procedures that on average took at least 500 microseconds.
* The third command compiles and instruments "compile.dart", this time
only instrumenting the procedures mentioned in the map
"cfe_compile_trace_candidates.txt".
* The forth command runs the instrumented compiler on "compile.dart".
This run shouldn't take significantly longer than a non-instrumented
run. It produces a new "cfe_compile_trace.txt" which this time is
not filtered. It also produces a file
"cfe_compile_trace_candidates_subsequent.txt" of recorded procedures
that on average took at least 50 microseconds.
* The fifth and sixth commands repeats the third and forth but
instrumenting only the procedures mention in
"cfe_compile_trace_candidates_subsequent.txt".
The third iteration might not be needed, but if the first run was on a
smaller input (which it isn't in this example) there might be some calls
that on average took long enough to be included in the candidate list
because the first call was slow and there were only very few of them,
making the second trace very big because there are now a lot of - as it
turns out - very quick calls recorded. Adding the third iteration will
filter (at least some of) those out.
Change-Id: I702c5c9142e525502b02f37744fcdc9d2b0f9b20
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296902
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL adds more benchmarking points, specifically giving more insight
into where body_buildBodies time goes.
It furthermore changes how overlapping subdivides are handled.
Previously only the first subdivide was actually recorded, meaning that
if a subdivide `a` contained a subdivide `b` only subdivide `a` would
have any time recorded for it. Now instead subdivide `b` will get data
recorded for the time it runs; this time will then _not_ be added to
`a`s total. For instance if subdivide `a` spends one second, then
(while still being in subdivide `a`) we enter subdivide `b` and spend
one second there, exit it, and spend yet another second before we exit
subdivide `a` before we would just have recorded 3 seconds for subdivide
`a`, now we will instead record 2 seconds for subdivide `a` and 1 second
for subdivide `b`.
Additionally a "system subdivide" is automatically added summarizing
any unaccounted for subdivide time, and an extra entry describing the
estimated subdivide recording overhead figues too.
As an additional note, enabling benchmarking seems to add ~6-7% runtime,
and because we specifically add additional parsing phases to measure
that separately the token stream can change before doing the actual
parsing, meaning that when enabling benchmarking some errors might be
swallowed.
Change-Id: I07ef42657c385031e8bb8680738442cf04fe2263
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295540
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This makes the socket benchmark (and real world code also), about 100x faster.
Change-Id: Iaa130b7bf69e4c89d3c3a221680e5b62ffe10583
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296641
Auto-Submit: Jake Macdonald <jakemac@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
In order for an analyzer quick fix to aid the user in correcting
exhaustiveness errors, it needs to know not just the text of the
witness pattern that needs to be inserted, but also which elements are
referenced by the identifiers in that pattern. This will allow it to
add in imports if the user's code doesn't yet import the necessary
library, or insert import prefixes in the case where the user is
already importing the necessary library in a prefixed fashion.
To reduce the effect on the exhaustiveness logic (which was designed
with the intention of building up the witness pattern into a
StringBuffer), we introduce a new type, `DartTemplateBuffer`, which
behaves similarly to StringBuffer but also captures the necessary
semantic information so that the analyzer will be able to fix up
imports in an appropriate way.
This change is mostly isolated to the _fe_analyzer_shared package; it
doesn't add the necessary logic to the analyzer to capture the
elements; it simply plumbs them up to the API boundary between the
packages. Future CLs will add the necessary analyzer logic to make
use of the information.
Change-Id: I7c030fc49a2510acbefd6aeb567e0e7b7102855a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/296385
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
This reverts commit df761ba9e7.
This also rebases the original CL onto HEAD so it can be landed first.
CoreLibraryReviewExempt: Reland of backend-specific library changes.
Change-Id: I4f9a017be3ec1924c021f941291d79d7aee06663
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294131
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
This includes introspection support, support for annotating and executing macros targeted at enums and enum entries, and support for creating library augmentations of enums with proper syntax (including enum entries).
I also refactored some of the Class support to be more general so we can share interfaces where appropriate.
Change-Id: Ie9111ff280405496e55e32478a19c104341aee37
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294100
Commit-Queue: Jake Macdonald <jakemac@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This reverts commit ef7d8d3f9a.
Reason for revert: Breaks Dart -> Engine roll?
See:
https://ci.chromium.org/ui/p/flutter/builders/try/Linux%20linux_web_engine/1821/overviewhttps://ci.chromium.org/ui/p/flutter/builders/try/Linux%20Engine%20Drone/666824/overview
Original change's description:
> [dart:js_interop] Export some package:js annotations and check them
>
> To disallow package:js on dart2wasm, we need to export @staticInterop
> and @anonymous through dart:js_interop. However, users should not mix
> the two @JS annotations, so we add some static checks for that. We also
> export @JSExport to support export classes with dart:js_interop.
>
> CoreLibraryReviewExempt: Reexporting annotations through backend-specific library.
> Change-Id: I54610965da332320170d991d785192341049607e
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293500
> Reviewed-by: Joshua Litt <joshualitt@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
Change-Id: I2af0755e054a1b0452a5fc617a93257209703793
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293961
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Zach Anderson <zra@google.com>
Reviewed-by: Zach Anderson <zra@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
To disallow package:js on dart2wasm, we need to export @staticInterop
and @anonymous through dart:js_interop. However, users should not mix
the two @JS annotations, so we add some static checks for that. We also
export @JSExport to support export classes with dart:js_interop.
CoreLibraryReviewExempt: Reexporting annotations through backend-specific library.
Change-Id: I54610965da332320170d991d785192341049607e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293500
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
This handles Never, and as a consequence, empty sealed types in
exhaustiveness. Since these contain no value, we should not try to
exhaust them. This avoid invalid non-exhaustive errors in these cases.
Included is handling of a scrutinee with invalid type as Never in the
CFE, thus avoid cascading non-exhaustive or unreachable errors.
Change-Id: Ife097731bb5399c42bf83f1d77aff773346adfb6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293682
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This reports an error when a pattern variable is assigned in the
guard of the case that declares it.
Change-Id: Ic9281350480d1eddcbbe4f35fba4ded4f35c13c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292892
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This reverts commit 645511d7f4.
Reason for revert: Deemed too risky to land so close to the release branch cut
Original change's description:
> Resolve package pubspec of target for relevant dartdev commands
>
> Adds a `--no-pub` flag to those commands
>
> Bug: https://github.com/dart-lang/sdk/issues/50422
> Change-Id: I949605c4ebb4c609eb19159625958317e54523a9
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291500
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Reviewed-by: Jonas Jensen <jonasfj@google.com>
> Reviewed-by: Johnni Winther <johnniwinther@google.com>
> Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
Bug: https://github.com/dart-lang/sdk/issues/50422
Change-Id: I465e43c59240e545658dce2e3fd764755d55ca97
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293560
Auto-Submit: Ben Konyi <bkonyi@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Siva Annamalai <asiva@google.com>
Also adds `firstOrNull`, `lastOrNull`, `singleOrNull`, and `elementAtOrNull`.
I chose `nonNulls` instead of `whereNotNull()`.
The latter should have been a getter, but isn't.
Making it a getter in the platform libraries would be confusing,
and make migrating from `package:collection`'s function harder,
so instead I gave it a completely new name.
The alternative would be to retain the non-idiomatic `whereNotNull()`
for familiarity. But then it would be tool late to fix.
Fixes#49928
BUG= https://github.com/dart-lang/sdk/issues/49928
CoreLibraryReviewExempt: Everybody's on vacation, everybody everywhere.
Change-Id: If464e3bd6bc97cbeefc3e5084b4cbaadac3f1e95
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290760
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Lasse Nielsen <lrn@google.com>
This change ensure that if the user makes an erroneous switch
expression by imitating the syntax of case statements (i.e. using
`case`, `default`, `:` instead of `=>`, or `;` instead of `,`), error
recovery will understand the user's intent, avoiding follow-on errors.
Fixes#51886.
Bug: https://github.com/dart-lang/sdk/issues/51886, https://github.com/dart-lang/sdk/issues/51943
Change-Id: Icd405d4fd4ddfb1aadcf0867e5a51ba898d4cdbc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293200
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This updates the message report for non-exhaustive switch statements
and expressions to include the witness in the problem message and
a reduced witness, which doesn't include properties that fully cover the
static type. The message is also split into two messages; one for
switch statements and one for switch expressions, allowing for a
better wording regarding the default/wildcard pattern case.
Change-Id: I17db657ef12ade5d47fa96bf69b8807e33ed5b8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293040
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
If the parser gets lost during a switch expression, it now attempts to
pick back up at the next `,` in between the curly braces (ignoring
more deeply nested commas). This allows much better error recovery in
the case where an illegal function expression appears in a guard.
Fixes#51906.
Bug: https://github.com/dart-lang/sdk/issues/51906
Change-Id: I1cb43857ccc04f0e4146c23c9e07acb02a80d405
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/293083
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The changes the MatchingCache to always create a new CacheExpression.
When the expression is cached the first CacheExpression is used
(the current behavior) but when the expression is not cached, each
individual CacheExpression is used. This ensures the file offsets match
the source location for the uncached expression.
In the updated VM test this shows up as the is-tests using all for
lines in the switch case and not just the first two.
In response to https://github.com/dart-lang/sdk/issues/51812
Change-Id: I2d7bdb54e11f212cd809899a50d827284c4f6657
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292082
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The precedence-based pattern parser can understand a unary pattern
inside another unary pattern (e.g. `_ as int as num`) or a relational
pattern inside a unary pattern (e.g. `> 1?`), but the specification
prohibits these constructions because they're difficult to read and
not very useful.
This change updates the implementation to match the spec, by producing
the appropriate error. The offset and length of the error cover the
inner pattern, so it should be easy to construct an analysis server
quick fix that inserts the necessary parentheses.
Bug: https://github.com/dart-lang/sdk/issues/50035
Change-Id: I33e74d6d1f863e7162851d26fefbacd4fd17277c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Adds a `--no-pub` flag to those commands
Bug: https://github.com/dart-lang/sdk/issues/50422
Change-Id: I949605c4ebb4c609eb19159625958317e54523a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291500
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Jonas Jensen <jonasfj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Sigurd Meldgaard <sigurdm@google.com>
The listener API for variable patterns is split into three separate
functions, to handle the three separate behaviors:
- `handleAssignedVariablePattern` for variable names appearing in an
assignment context (these assign to an existing variable upon a
successful match).
- `handleDeclaredVariablePattern` for variable declarations appearing
in a declaration or matching context (these cause a new variable
name to come into scope).
- `handleWildcardPattern` for wildcards in any context (these don't
capture the matched value).
Also, responsibility is shifted to the parser for reporting the
following error conditions:
- VariablePatternKeywordInDeclarationContext (e.g.
`var (var x) = ...;`)
- PatternAssignmentDeclaresVariable (e.g. `[x, var y] = ...;`)
Previously these errors were detected by the implementations, and
weren't fully covering all possible error scenarios.
In the case of VariablePatternKeywordInDeclarationContext, the
listener method `handleDeclaredVariablePattern` is called instead of
`handleAssignedVariablePattern`. This ensures that no tokens are
dropped from the analyzer AST. The CFE uses the `inAssignmentPattern`
argument of `handleDeclaredVariablePattern` to distinguish this error
recovery case from a legitimate declared variable pattern.
Fixes#51868.
Bug: https://github.com/dart-lang/sdk/issues/51868
Change-Id: I28ec679b73d64033166721c6460be35f15e23171
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291583
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Added error messages for when users try to use invalid mixins + a language test that tests that (and tests in each of the front ends).
Removed the tokens from the parser listeners.
Removed all behaviours and error reporting related to these invalid mixins.
Change-Id: I558595826dae7e2c176bd1929e97caa2335c167c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290614
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This updates the checking order of the exhaustiveness algorithm to
process the sealed type on its own before checking the subtypes. This
has the benefit that for fields that fully covered by (a supertype of)
the sealed type itself, like a wildcard pattern, we avoid checking
each individual subtype.
For the exponential cases added in
https://dart-review.googlesource.com/c/sdk/+/291800
this avoids the exponential growth, bringing the number of checked
witness candidates from 837932 to 6 for the "subtype" test with n = 30 and from 12207032 to 12 for the "fields" test with n = 10.
The change also fixes a problem in the 'future_or_members.dart' caused by the non-null version of 'FutureOr<dynamic>' still being nullable. The old algorithm tried to use 'Object' as a witness canditate but filtered out 'FutureOr<dynamic>' because 'Object' wasn't a subtype if it. The new algorithm starts by using 'Object?' and therefore sees that 'FutureOr<dynamic>' exhausts it. This is an inherent problem in the modelling of StaticType and it should still be addressed.
Change-Id: Iaa5d5604afc4662fe1983d670638223eae5dbf6b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291822
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds handling of type variables with bounds and intersection types
in exhaustiveness checking. These are handled using [WrappedStaticType]s
where the type variable is the implied type and the bound is the
wrapped type from which the subtypes are computed, thereby supporting
sealed types in the bounds.
The change also includes some cleanups a fixes found during
implementation, amongst these a fix to no longer cache the map/list
type identities objects. These were not used as identities, similar to
the value identities used for enum and bool values, but instead as
restrictions on the the static type. These have therefore been renamed
to Map/ListTypeRestriction to reflect that.
Closes https://github.com/dart-lang/language/issues/2878Closes#51819
Change-Id: I56e94e4f0dc6695288ab978687d8c95835535b8d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291220
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The spec uses the terms "upwards" vs "downwards" inference to refer to
whether type constraints come from a return type or parameter types.
Previous to this change the code used the terms "upwards" vs "partial"
inference to refer to whether the types being chosen were preliminary
(and hence might contain `?`s) or were the final inferred types. This
led to confusion; for example the method
`downwardInferObjectPatternRequiredType` was calling `upwardsInfer`.
This change adjusts the nomenclature so that the methods that choose
types are called `choosePreliminaryTypes` and `chooseFinalTypes`, to
avoid any confusion with the direction of inference.
See discussion here:
https://dart-review.googlesource.com/c/sdk/+/290613/comment/894a767c_e269584e/.
Change-Id: Ie05dcae027ca82b2ce7e5a57f1846412d5b32d50
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290901
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This updates the toString on Witness to produce pattern code. The
created pattern is directly derived from the predicates of the
witness and there contain some needless precision, for instance
`[...[...]]` instead of `[...]`. It is the plan to address this in
a follow-up.
Change-Id: Ied7930f36b1e1818540b8c635b18ff92f28e113b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/290720
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL adds support for strict mode, but disables it in tests and
allowed packages.
Change-Id: I834bc5a0e88868b282c3901361f7a90e1f9eeb3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289621
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Joshua Litt <joshualitt@google.com>
Includes a fix for matched value type being invalid, encountered
during development.
Closes#51770
Change-Id: I0c960eaef528f16789e8d9a42340e50f05326cf7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/289602
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
