Weaves the flag `inference-update-4` through to `FlowAnalysis` and updating both the analyzer and CFE point-of-entry to include the flag.
This flag will be used in `flow_analysis.dart` to hide upcoming bug fixes to flow analysis.
Change-Id: Ib0004eb4bcf0b6e579116632b5973fe969e51e90
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388582
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This CL changes the CFE's
TypeConstraintGatherer._isNullabilityAwareSubtypeMatch method so that
it is responsible for restoring the constraint state if there is no
match, making it consistent with the contraint gathering methods in
the analyzer and _fe_analyzer_shared.
This made it possible to remove much of the calls to state restoring
logic that _isNullabilityAwareSubtypeMatch previously had to do after
making recursive calls to itself, as well as a lot of state restoring
logic in _fe_analyzer_shared. It also made it possible to eliminate
_tryNullabilityAwareSubtypeMatch from the CFE (since
_isNullabilityAwareSubtypeMatch now has the same behavior).
Making this change now should hopefully simplify the remaining steps
in sharing type variable constraint generation logic, since it will no
longer be necessary to adjust state restoring logic when moving code
between the CFE and _fe_analyzer_shared.
I also took the liberty of rewriting some of the documentation
comments to try to clarify the new conventions.
In the process I also discovered several instances of unnecessary
state restoring logic in the analyzer; I'll make a separate CL to
clean those up (and adjust the analyzer documentation too).
Change-Id: If74c8be06f1d53f61d109e5ea2a8526d5cbcd347
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388265
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Auto-Submit: Paul Berry <paulberry@google.com>
Previously, the base `ExpressionInfo` class contained four fields:
- `type`: the type of the expression.
- `ifTrue`: a flow model describing the state of the program after the
expression is evaluated, assuming the expression evaluates to
`true`.
- `ifFalse`: a flow model describing the state of the program after
the expression is evaluated, assuming the expression evaluates to
`false`.
- `after`: a flow model describing the state of the prorgam after the
expression is evaluated, making no assumptions about what value the
expression evaluates to.
The `after` field was largely redundant, since it tracked the same
information as `FlowAnalysisImpl._current`. In fact, flow analysis
contained a substantial amount of code to copy from
`ExpressionInfo.after` to `FlowAnalysisImpl._current`, or vice versa,
in order to keep the two in sync.
The one exception was in `FlowAnalysisImpl.conditional_end`, which is
called at the end of visiting a conditional expression (`e1 ? e2 :
e3`): it joined the `after` flow models from `e2` and `e3` in order to
determine the state of the program after the conditional expression
completes. To preserve this behavior, a small amount of extra
accounting logic had to be added to the handling of conditional
expressions, to keep track of these flow models. (`e2.after` is now
stored in `_ConditionalContext.thenModel`, and `e3.after` comes from
the state of `_current` at the time of entry into
`FlowAnalysisImpl.conditional_end`).
Change-Id: I46e771f8b029550d43a5fe50366177f189a6a91d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388081
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Kallen Tu <kallentu@google.com>
This brings the "mini types" representation of records (which is used
for _fe_analyzer_shared unit tests) into alignment with the behavior
of analyzer and CFE record types (which sort their fields), and makes
the representation more consistent with that of function types.
Since all implementations of record types now maintain named fields in
sorted order, documentation has been added to
SharedRecordTypeStructure to indicate that the fields returned by the
`namedTypes` getter are sorted.
This exposed a minor bug in the error recovery logic in the shared
pattern type analyzer: upon encountering a record pattern with
duplicate field names, after reporting the appropriate error, it would
nonetheless attempt to create a record type containing duplicate
fields (potentially breaking the assumptions made by other code that
handles record types). This bug was fixed by adjusting the record
pattern analysis logic so that it drops duplicate field names when
constructing record types.
Change-Id: Ib06b86df980afcf17896e10ac7856f994aeda86f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/388041
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously, the "mini types" representation used in
`_fe_analyzer_shared` unit tests represented unpromoted type
parameters using the `PrimaryType` class (which was also used for
interface types and special built-in types like `void`) and
represented promoted type parameters using a separate
`PromotedTypeVariableType` class.
This CL changes the "mini types" representation to use a single
`TypeParameterType` class for both unpromoted and promoted type
parameters. This parallels the representation used by the analyzer
and CFE, so it should help pave the way for sharing type system logic
between the analyzer and CFE.
To allow the `Type` constructor to distinguish whether a given
identifier represents an interface type or a type variable, tests must
register all type names they will need, using either the static method
`TypeRegistry.addTypeParameter` or the static method
`TypeRegistry.addInterfaceTypeName`.
To prevent the type names registered by one unit test from interfering
with those registered by another, tests should call
`TypeRegistry.init` in a `setUp` callback and `TypeRegistry.uninit` in
a `tearDown` callback. Methods in `TypeRegistry` contain error checks
to help make sure these calls aren't forgotten.
Change-Id: I701842ad94899c819f1a059e660510a616d00456
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/387822
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change combines function-handling logic from the analyzer's
`TypeConstraintGatherer._functionType0` and the CFE's
`TypeConstraintGatherer._isNullabilityAwareSubtypeMatch` methods into
`TypeConstraintGenerator.performSubtypeConstraintGenerationForFunctionTypes`,
which is in `_fe_analyzer_shared`.
The CFE and the analyzer have some pretty significant differences in
how they represent function types:
- In the analyzer, all function parameters are in a single
`parameters` list; each element of this list (of type
`ParameterElement`) can be queried to find out if it is named or
unnamed, and if it is required or optional. A convention enforced
partially by the `FunctionType` constructor is that the `parameters`
list stores reqired unnamed parameters first, then either optional
unnamed parameters or named parameters; named parameters are sorted
by name. The analyzer provides additional getters
`namedParameterTypes`, `normalParameterNames`,
`normalParameterTypes`, `optionalParameterNames`, and
`optionalParameterTypes`, which provide other views of this
information (for example, `namedParameterTypes` contains just the
named parameters, as a map from name to `ParameterElement`).
- In the CFE, unnamed and named parameters are in two separate lists
(`positionalParameters`, of type `List<DartType>`, and
`namedParameters`, of type `List<NamedType>`); in
`positionalParameters`, required parameters come before optional
ones. A single integer (`requiredParameterCount`) indicates how many
elements of `positionalParameters` are required, and by convention,
`namedParameters` is sorted by name.
In order to share logic between these representations, I had to come
up with a common API that these two representations could be easily
adapted to. The analyzer's representation proved to be easier to
adapt, so I based the common API mostly on the CFE's representation,
but with some name changes for clarity. The shared API is:
- `positionalParameterTypes` gets a list of positional parameter types
- `requiredPositionalParameterCount` tells how many entries in
`positionalParameterTypes` are required.
- `returnType` gets the function type's return type.
- `sortedNamedParameters` gets a list of information about named
parameters. The list elements are sorted by name, and each element
of this list is of type `FunctionParameterStructure` (a common
interface implemented both by the analyzer's `ParameterElement` and
the CFE's `NamedType`).
- `typeFormals` gets a list of the function type's formal type
parameters.
To minimize the performance impact of adapting the analyzer to this
API, the analyzer computes `positionalParameterTypes`,
`requiredPositionalParameterCount`, and `sortedNamedParameters` at the
time a `FunctionType` is constructed. Hopefully this should not be too
much of a performance hit, since doing so does not take too much more
effort than checking that the named parameters are sorted (which the
`FunctionType` constructor was already doing).
This is based on previous work by Chloe Stefantsova in
https://dart-review.googlesource.com/c/sdk/+/386480.
Change-Id: Iefe18d72771146399d81747ceab9c929516b0523
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386322
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This splits up [computeAmbiguousDeclarationForScope] into
[computeAmbiguousDeclarationForExport], which is moved to [LibraryBuilder], and [computeAmbiguousDeclarationForImport].
Change-Id: I2fad4784904eef6caf731a41300b98c6f172039d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/387080
Reviewed-by: Jens Johansen <jensj@google.com>
Mini-ast function types now support optional positional parameters and
named parameters (both required and optional).
This will allow more _fe_analyzer_shared functionality to be unit
tested.
Change-Id: I3425e0742de2bee511f2f3d303dd3ed6f26c289c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386729
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
These tests cover just the portion of the subtype constraint
generation mechanism that's currently shared between the analyzer and
the CFE. I plan to add more unit tests as more functionality becomes
shared.
Note that as part of this change, I've eliminated the methods
`performSubtypeConstraintGenerationForFutureOrRightSchema` and
`performSubtypeConstraintGenerationForFutureOrLeftSchema`, and instead
made `_performSubtypeConstraintGenerationForFutureOrInternal` public
(renaming it to `performSubtypeConstraintGenerationForFutureOr`). My
rationale for this change is as follows:
- It makes testing easier, since only one method needs to be tested
rather than two.
- Removing these two methods simplifies the call sites in the analyzer
and CFE, since instead of having to use an `if` test to decide which
method to call, they can simply pass in the appropriate boolean
switch for the `leftSchema` argument.
Change-Id: I0911c80fc8e9a4fbdd3dd0063dd203066006c218
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386861
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The return type of this method was previously
`TypeDeclarationMatchResult?` (with no explicit type arguments),
meaning that the generic type parameters of
`TypeDeclarationMatchResult` would be filled in by
instantiate-to-bounds as `Object, Object, Object`. But the
implementations always return the more precise type
`TypeDeclarationMatchResult<TypeDeclarationType, TypeDeclaration,
TypeStructure>?`, and the use sites all expect this type. Adding
explicit type arguments improves type safety and probably allows the
compiler to elide some of the type casts involved in pattern matching.
Also, the "mini_ast" implementation of this method contained a subtle
bug: instead of using `unwrappedType.type` for the `typeDeclaration`
Change-Id: Ic7bffc1b0b3e9bfc86c0168d4e6bdf442af8ae39
argument, it should use `unwrappedType.name`. This ensures that if the
type being matched is generic, the generic arguments don't show up in
the `typeDeclaration`.
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386681
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Previously the implementation of this method was a stub.
It turns out that all the necessary infrastructure was in place
already, however the type arguments supplied by MiniAstOperations to
TypeAnalyzerOperationsMixin and TypeAnalyzerOperations needed to be
changed: in the "mini_ast" representation of types, an
InferableParameter is represented by a String, not a
PromotedTypeVariableType. This is because InferableParameter is meant
to represent the declaration of the type parameter
(StructuralParameter for the CFE, TypeParameterElement for the
analyzer), not the type itself. The types used for unit testing in
_fe_analyzer_shared don't have a separate notion of the declaration of
a type parameter, so we just use its name.
Implementing this logic required adding a method
`TypeSystem.matchTypeParameterType`, which checks if a Type is a type
parameter type, and returns the name of the type parameter if so. I
based this on the previously existing `TypeSystem._isTypeVar` method
(which performed the same job but did not return the type parameter
name).
I also took the liberty of fixing a flow analysis test that treated
`T` as a type variable but failed to mark it as a type variable by
calling `addTypeVariable`.
This should help pave the way for unit testing more of the shared
infrastructure for types.
Change-Id: Ia7a9777ec3d90a5886567dcb9f831e388e372f32
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/386607
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The (utf8) scanner currently has this thing where you give it a
0-terminated byte-array (i.e. you read the file, then allocate
something that's 1 bigger, copy the data, then give it to the scanner)
to 'avoid bounds checks'.
Dart still has bounds checks though - they're just implicit.
As for the string scanner ut gets a string, then creates a new string
like `string + '\x00'` - so basically the same thing.
This CL uses the 'vm:unsafe:no-bounds-checks' pragma, removing the
implicit bounds checks, adding explicit bounds checks,
saving ~73.6 mio instructions when compiling the CFE in the process:
```
Comparing snapshot #1 with snapshot #2
cycles:u: -0.9983% +/- 0.6563% (-174026333.30 +/- 114410028.98)
instructions:u: -0.3416% +/- 0.0005% (-73659267.00 +/- 108567.20)
branch-misses:u: -4.8952% +/- 2.2612% (-3172939.50 +/- 1465641.18)
```
With the scanner-benchmark with `--bytes` I get this:
```
msec task-clock:u: -1.2251% +/- 0.6355% (-50.64 +/- 26.27)
cycles:u: -1.2376% +/- 0.6385% (-223642830.80 +/- 115393789.68)
instructions:u: -2.8155% +/- 0.0000% (-1153243856.00 +/- 428.11)
seconds time elapsed: -1.2165% +/- 0.6408% (-0.05 +/- 0.03)
seconds user: -1.1539% +/- 0.6495% (-0.05 +/- 0.03)
```
With the scanner-benchmark with `--string` I get this:
```
msec task-clock:u: -7.6439% +/- 0.6628% (-366.08 +/- 31.74)
page-faults:u: -95.0034% +/- 0.0014% (-228023.50 +/- 3.41)
instructions:u: 2.1041% +/- 0.0000% (897941907.60 +/- 2082.79)
branch-misses:u: 3.2994% +/- 1.4675% (3239735.30 +/- 1440940.88)
seconds time elapsed: -7.6595% +/- 0.6610% (-0.37 +/- 0.03)
seconds user: -0.8801% +/- 0.7676% (-0.04 +/- 0.03)
seconds sys: -92.0140% +/- 2.8075% (-0.33 +/- 0.01)
MarkSweep( old space) goes from 6 to 0
Notice combined GC time goes from 112 ms to 41 ms (notice only 1 run each).
```
Where I'll note that the 'vm:unsafe:no-bounds-checks' pragma doesn't
(yet?) work for `String.codeUnitAt`.
See https://dart-review.googlesource.com/c/sdk/+/384540
(and https://dart-review.googlesource.com/c/sdk/+/385201) for details.
I assume the relatively big change here is caused by not allocating
a new string with a 0-byte in the end each time.
Note that the read-allocate-copy dance is still performed for the utf8
scanner in this CL as it requires changing all call-sites instead.
It will be done in a follow-up CL where the "end-of-file" int will
likely also be changed to `-1` to (I assume) allow for having the
0-byte in the middle of a file (see also the 10+ year old bug at
https://github.com/dart-lang/sdk/issues/18090)
Note: The pragma (currently?) only has effect in AOT and this change
will (for the utf8 scanner) make the JIT version slower
(probably by the same ~73.6 mio instructions as - at least in AOT -
the implicit check is 6 instructions and the explicit one is 3
instructions). As the pragma doesn't work in the StringScanner anyway
I expect the change to be somewhat equivalent there. Once the
read-allocate-copy dance is also removed from the utf8 scanner I expect
the combined result to be positive all around.
Update: With https://dart-review.googlesource.com/c/sdk/+/385201 landed
I get these changes:
Compiling the CFE:
```
instructions:u: -0.4520% +/- 0.0002% (-98470955.29 +/- 42253.40)
```
Scanner benchmark with `--bytes`:
```
msec task-clock:u: -2.1758% +/- 0.2316% (-92.07 +/- 9.80)
cycles:u: -2.1941% +/- 0.2283% (-405224983.11 +/- 42160655.88)
instructions:u: -3.1049% +/- 0.0000% (-1272360052.95 +/- 706.54)
branch-misses:u: 2.4718% +/- 0.5142% (2371345.23 +/- 493257.76)
seconds time elapsed: -2.1761% +/- 0.2317% (-0.09 +/- 0.01)
seconds user: -2.2071% +/- 0.2308% (-0.09 +/- 0.01)
```
Scanner benchmark with `--string`:
```
msec task-clock:u: -15.0073% +/- 0.2175% (-745.93 +/- 10.81)
page-faults:u: -95.0035% +/- 0.0003% (-228024.25 +/- 0.81)
cycles:u: -7.7986% +/- 0.2329% (-1558985588.99 +/- 46560962.79)
instructions:u: -3.7054% +/- 0.0000% (-1581977447.66 +/- 481.68)
branch-misses:u: -0.6880% +/- 0.5818% (-689453.22 +/- 583101.50)
seconds time elapsed: -15.0198% +/- 0.2170% (-0.75 +/- 0.01)
seconds user: -8.8149% +/- 0.2648% (-0.41 +/- 0.01)
seconds sys: -94.1247% +/- 1.6444% (-0.34 +/- 0.01)
MarkSweep( old space) goes from 6 to 0
```
Change-Id: I524a21f488da7df5dc9d2cdf40112b84896ad3e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383324
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Short explanation: For whatever reason, when using `identical` on `int`s
the ints are first boxed (`BoxInt64`) before being compared
(`StrictCompare`) whereas just doing `==` just does a compare
(`EqualityCompare`).
Results:
With the CFE compiling (a fixed version of) itself I get these results:
```
instructions:u: -0.5756% +/- 0.0003% (-124825401.80 +/- 64013.17)
```
i.e. almost 125 mio instructions saved.
Another run - with 100 iterations each - I get
```
msec task-clock:u: -0.4927% +/- 0.2585% (-20.85 +/- 10.94)
page-faults:u: 0.0174% +/- 0.0139% (18.80 +/- 15.00)
cycles:u: -0.5233% +/- 0.2683% (-91305451.82 +/- 46815747.30)
instructions:u: -0.5754% +/- 0.0002% (-124793061.49 +/- 37426.30)
branch-misses:u: -1.6903% +/- 1.1207% (-1091410.69 +/- 723627.04)
seconds time elapsed: -0.4863% +/- 0.2581% (-0.02 +/- 0.01)
seconds user: -0.4547% +/- 0.3253% (-0.02 +/- 0.01)
```
In the scanner benchmark with `--string` (i.e. using string scanner) I
get these results:
```
msec task-clock:u: -3.7992% +/- 0.3316% (-190.54 +/- 16.63)
cycles:u: -4.1423% +/- 0.3566% (-836808313.28 +/- 72033424.19)
instructions:u: -3.3524% +/- 0.0000% (-1480262370.08 +/- 828.58)
branch-misses:u: -1.7591% +/- 0.9582% (-1781144.28 +/- 970258.82)
seconds time elapsed: -3.7988% +/- 0.3303% (-0.19 +/- 0.02)
seconds user: -4.0211% +/- 0.4161% (-0.19 +/- 0.02)
```
(Just running the benchmark also sees the characters/µs go from ~93 to
~97).
In the scanner benchmark with `--bytes` (i.e. using the utf8 scanner) I
get these results:
```
msec task-clock:u: -4.2872% +/- 0.4467% (-185.64 +/- 19.34)
cycles:u: -4.2972% +/- 0.4382% (-812955454.92 +/- 82892232.23)
instructions:u: -3.4867% +/- 0.0000% (-1479744935.28 +/- 297.12)
seconds time elapsed: -4.2872% +/- 0.4470% (-0.19 +/- 0.02)
seconds user: -4.2204% +/- 0.4730% (-0.18 +/- 0.02)
```
(Just running the benchmark also sees the bytes/µs go from ~108 to ~113).
In both cases we notice how the actual time, cycles and instructions
agree pretty well.
Combining the data for the compile and the benchmark I assume this CL
actually reduces the runtime of the CFE compiling itself by a about
half a percent.
Change-Id: I67d056837240aef61b6707d02507ab4121b31715
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385940
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
E.g. we might do this
```
$ out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot pkg/_fe_analyzer_shared/test/scanner_benchmark.dart
Generated: /usr/local/google/home/jensj/code/dart-sdk/sdk/pkg/_fe_analyzer_shared/test/scanner_benchmark.aot
$ for type in --bytes --bytes0 --string --stringtobytes --count ; do out/ReleaseX64/dart-sdk/bin/dartaotruntime pkg/_fe_analyzer_shared/test/scanner_benchmark.aot pkg/kernel/lib/ast.dart $type; done
Scanned 466534 bytes 1000 times in 0:00:04.413011
Found errors 0 times
That's 105.71784208106438 bytes per microsecond
Scanned 466534 bytes 1000 times in 0:00:04.911947
Found errors 0 times
That's 94.97944501437007 bytes per microsecond
Scanned 466532 string characters 1000 times in 0:00:05.413169
Found errors 0 times
That's 86.18463602374136 string characters per microsecond
Scanned 466532 string characters as bytes 1000 times in 0:00:06.722731
Found errors 0 times
That's 69.39620222793386 string characters as bytes per microsecond
Scanned 466534 bytes 1000 times in 0:00:00.641854
Found errors 0 times
That's 726.8537704836302 bytes per microsecond
```
to see that scanning pre-0-at-the-end'ed bytes scan at ~105 bytes/µs,
doing a copy to add the 0 at then end, then parse bytes scan at ~95,
scanning strings runs at ~86, converting strings to bytes, then scanning
the bytes at ~69 and - for comparision - just running through the bytes
counting linebreaks runs at ~726.
The benchmark is also useful for comparing optimizations.
Change-Id: I67c12850505e7f712660fd353575e8c7a455f112
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/385920
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
When determining whether a switch statement is exhaustive, it's
important for the exhaustiveness algorithm to ignore cases containing
`when` clauses, since a `when` clause creates the possiblity that the
case won't match.
Previously, the way this was done in the analyzer was for the
`SpaceCreator.createRootSpace` method to create an unknown space for
cases containing `when` clauses. This approach produced the correct
behavior when determining whether the switch statement as a whole was
exhaustive, but since it discarded information about the pattern being
matched, it limited the ability to determine whether an individual
case was reachable, leading to
https://github.com/dart-lang/sdk/issues/56710.
To fix this, `SpaceCreator.createRootSpace` is changed so that it
always produces a space that describes the case pattern, regardless of
whether a `when` clause is present, and instead,
`computeExhaustiveness` is responsible for ensuring that the case is
properly excluded from the determination of whether the switch is
exhaustive. This allows `computeExhaustiveness` to properly computate
whether each individual case is reachable, even for cases that have
`when` clauses.
This change in approach produced some minor differences in the test
cases in `pkg/_fe_analyzer_shared/test/exhaustiveness/data`, but these
differences are not user-observable.
Fixes https://github.com/dart-lang/sdk/issues/56710.
Change-Id: I36629a77c4c1832fb1b8abb6ea7b109e0ca14373
Bug: https://github.com/dart-lang/sdk/issues/56710
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/384326
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- Rename resource identifiers in the VM to usage recordings.
- Use package:record_use for serialization.
- Rename and use the experimental flag for this feature.
- Recognize tear-offs and top-level methods as well.
Next steps:
- Add constant instance recording.
- Expose API in package:native_assets_cli's link callback.
TEST=pkg/vm/test/transformations/record_use_test.dart
Change-Id: I8af3625165f78925ae943711245af93a239d1012
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383040
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Moritz Sümmermann <mosum@google.com>
This warning is similar to the existing `UNREACHABLE_SWITCH_CASE`
warning, except that it warns if the `default` clause of a switch
statement is unreachable due to all the `case` clasuses fully
exhausting the switched type.
To make the implementation easier, I changed the API for the
`reportExhaustiveness` method in `_fe_analyzer_shared` (which is the
primary entry point to the shared exhaustiveness checker). Previously,
this method returned a list of `ExhaustivenessError`, where each list
element was either an `UnreachableCaseError` (indicating that a
certain case was unreachable) or a `NonExhaustiveError` (indicating
that the entire switch statement was not exhaustive). If the caller
passed in `false` for `computeUnreachable`, `UnreachableCaseError`s
would not be returned, so the returned list would either be empty or
contain a single `NonExhaustiveError`.
The new API renames the types for clarity:
- `NonExhaustiveError` becomes `NonExhaustiveness`, to highlight the
fact that it's not necessarily an error for the switch's cases to be
non-exhaustive; it's only an error if the scrutinee's static type is
an "always exhaustive" type and there is no `default` clause.
- `UnreachableCaseError` becomes `CaseUnreachability`, to highlight
the fact that it's not an error for a case to be unreachable; it's a
warning.
Also, the new API adds instances of `CaseUnreachability` to an
optional user-provided list instead of returning a newly created list;
this allows callers to communicate that they don't need to see
`CaseUnreachability` information by passing `null`. This frees up the
return type to simply be an instance of `NonExhaustiveness` (if the
cases are not exhaustive) or `null` (if they are exhaustive). This
makes it easier for the analyzer to decide whether to issue the new
warning, because it doesn't have to dig around the list looking for an
instance of `NonExhaustiveness`.
The new warning has an associated quick fix (remove the unreachable
`default` clause). This quick fix uses the same `RemoveDeadCode` logic
in the analysis server that the existing `UNREACHABLE_SWITCH_CASE`
warning uses.
Fixes https://github.com/dart-lang/sdk/issues/54575.
Bug: https://github.com/dart-lang/sdk/issues/54575
Change-Id: I18b6b7c5249d77d28ead7488b4aae4ea65c4b664
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378960
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Erik Ernst <eernst@google.com>
This adds the enclosingDeclarationName to the beginMethod of the
parser listener.
This enables the removal BuilderFactory.currentTypeParameterScopeBuilder.
Change-Id: Ie2bec9432c20b8bdbd62a14e8a65c272179d4698
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/383182
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This CL primarily adds a lint for fields with `StackTrace.current`
which is often useful for debugging, but shouldn't be left in.
* Add an ast visitor after the "explicit creation test",
finding - for now - `StackTrace.current` calls in fields.
This should have caught the left-in debug such in
https://dart-review.googlesource.com/c/sdk/+/379281.
* Renamed explicit_creation to compile_and_lint
* Remove (for some time) unused "smoke_test_quick" files.
* Add kernel to the compile_and_lint suite, but ignore it for explicit
creation (i.e. kernel will also be checked for fields
with `StackTrace.current`).
Change-Id: Ib886d23a8945e7063dc673a7f99cbb3a6adc1139
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382361
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Previously, performSubtypeConstraintGenerationForFutureOrLeftSchema
and performSubtypeConstraintGenerationForFutureOrRightSchema had
almost identical implementations. The purpose of those methods was to
provide two differently typed entry points to the same algorithm. This
CL reduces the code duplication by introducing
performSubtypeConstraintGenerationForFutureOrInternal that the two
entry points simply redirect to.
Part of https://github.com/dart-lang/sdk/issues/54902
Change-Id: Idd545eed3cba67882f81b68e9b69ccf1aecb4257
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382164
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
The scanner, when creating StringTokens cuts out the substring lazily if
their length is above some threshold. The work is then only done when
and if we actually need the string.
This makes sense for the cases where we normally do not need the string.
In the CFE we scan all sources twice: Once for building the outline, and
once for building the bodies.
When building the bodies we in almost always actually need the string
anyway (something along the lines of we don't ask for <400 out of over
400,000 when compiling the CFE itself).
This CL opts the CFEs second scan (when building bodies) out of the lazy
strings, copying the substrings up front, avoiding the creation of
intermediary `_LazySubstring` (`_CompactLazySubstring` /
`_FullLazySubstring`).
With an AOT compile of the CFE, compiling itself, 50 runs gives these
statistics:
```
msec task-clock:u: -1.3619% +/- 0.3329% (-57.88 +/- 14.15)
page-faults:u: -1.1453% +/- 0.0162% (-1163.82 +/- 16.44)
cycles:u: -1.4138% +/- 0.3433% (-248274774.52 +/- 60279949.79)
instructions:u: -0.5573% +/- 0.0003% (-120171914.10 +/- 59862.46)
branch-misses:u: -3.2906% +/- 1.4496% (-2192237.90 +/- 965762.85)
seconds time elapsed: -1.3662% +/- 0.3338% (-0.06 +/- 0.01)
seconds user: -1.3354% +/- 0.3715% (-0.05 +/- 0.01)
Scavenge( new space) goes from 63 to 62
```
25 other runs gave these:
```
msec task-clock:u: -0.7929% +/- 0.4759% (-33.69 +/- 20.22)
page-faults:u: -1.1654% +/- 0.0176% (-1184.36 +/- 17.88)
cycles:u: -0.7756% +/- 0.5043% (-136122352.96 +/- 88506748.30)
instructions:u: -0.5578% +/- 0.0005% (-120265633.72 +/- 115062.27)
seconds time elapsed: -0.7852% +/- 0.4726% (-0.03 +/- 0.02)
Scavenge( new space) goes from 63 to 62
```
So it seems likely that new space GCs go from 63 to 62, theat the
instruction count goes down by 0.55% and that it's actually around 1% faster.
Change-Id: Ic462a67db7274cc8ed38df7f3ed9f41f7497fc82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/382162
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This CL removes Type and TypeSchema type variables from the abstract
classes with shared code between the CFE and the analyzer. Extension
types SharedTypeView and SharedTypeSchemaView are declared to replace
the type variables.
The update propagates the discipline of distinguishing between types
and type schemas into the clients of the shared code. Now the code in
the CFE and the Analyzer that uses the shared code needs to statically
specify the interpretation of their type objects as either types or
type schemas.
Another benefit of the update is SharedTypeView and
SharedTypeSchemaView being less opaque than the Type and TypeSchema
type variables, which removes the necessity for some code duplication
in abstract methods for types and type schemas.
Finally, the update enables some further changes in the shared code
between the Analyzer and the CFE.
Change-Id: I88e8cfcd47d4f721974b4f2612521e85bb54c30f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/379302
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
This adds an explicit computation for the nullability of type variables
while taking cyclic dependencies into account. This removes the need
for post-processing of pending nullabilities.
Change-Id: Ic7c42eef8270610d3b4f1d27ea0067c80df88daa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381242
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This changes the BodyBuilder to create FunctionTypeParameter instead
of FormalParameterBuilder for "parameters" in function types. This
avoids the creation of unnecessary VariableDeclaration nodes
function types.
The types of these VariableDeclarations where created before the type
variable scope was completed, introducing an artificial dependency on
the pending nullability computation.
Change-Id: Ie1203fa4c78a27f3e7a0dfad16725cbbde24a6a1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/381143
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
SharedType and its subtypes now all declare one recursive type
variable Type with the bound SharedType<Type>. It allows to treate
SharedType and its subtypes as an abstract familty of types that has a
specific structure.
More specifically, the type variables Type and TypeSchema in the
abstract classes for shared algorithms between the Analyzer and the
CFE can now be defined recursively as extending SharedType<Type> and
SharedType<TypeSchema>, giving both types and type schemas the
structure of the family of types with the root at SharedType.
One of the benefits for that is that some abstract members become
unnecessary. For example, a type or type schema can now be tested for
having the shape of the type 'dynamic' with a direct is-check,
comparing them, correspondingly, with SharedType<Type> and
SharedType<TypeSchema>.
More importantly, having the family of recursive types lays the
foundation for further work on sharing the type structure between the
Analyzer and the CFE.
Change-Id: I67904f878668c035702092e8c21d3ce66f5ca469
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/378700
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Adds a new `@Array.variable()` to specify that the last element of
structs is a variable length inline array.
This CL does not add any checks for passing structs with variable
length inline arrays by value or directly calling them with
`AllocatorAlloc.call`. Instead, the implementation defaults to what
C does, allocate as if there are 0 elements in the variable length
inline array.
TEST=tests/ffi/*
CoreLibraryReviewExempt: VM only
Closes: https://github.com/dart-lang/sdk/issues/55964
Change-Id: I524d8a1d710b1a744b392e05fa884908c3ff1f12
Cq-Include-Trybots: dart/try:vm-aot-android-release-arm64c-try,vm-aot-android-release-arm_x64-try,vm-aot-asan-linux-release-x64-try,vm-aot-linux-debug-x64-try,vm-aot-linux-debug-x64c-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-msan-linux-release-x64-try,vm-aot-obfuscate-linux-release-x64-try,vm-aot-optimization-level-linux-release-x64-try,vm-aot-tsan-linux-release-x64-try,vm-aot-ubsan-linux-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64-try,vm-aot-win-debug-x64c-try,vm-appjit-linux-debug-x64-try,vm-asan-linux-release-arm64-try,vm-asan-linux-release-x64-try,vm-checked-mac-release-arm64-try,vm-eager-optimization-linux-release-ia32-try,vm-eager-optimization-linux-release-x64-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-ffi-qemu-linux-release-riscv64-try,vm-fuchsia-release-arm64-try,vm-fuchsia-release-x64-try,vm-linux-debug-ia32-try,vm-linux-debug-x64-try,vm-linux-debug-x64c-try,vm-mac-debug-arm64-try,vm-mac-debug-x64-try,vm-msan-linux-release-arm64-try,vm-msan-linux-release-x64-try,vm-reload-linux-debug-x64-try,vm-reload-rollback-linux-debug-x64-try,vm-tsan-linux-release-arm64-try,vm-tsan-linux-release-x64-try,vm-ubsan-linux-release-arm64-try,vm-ubsan-linux-release-x64-try,vm-win-debug-arm64-try,vm-win-debug-x64-try,vm-win-debug-x64c-try,vm-win-release-ia32-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/371960
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Konstantin Shcheglov