Do not revert: The main channel version must be upgraded now that the
version 3.3 beta has been cut and reverting this change puts the
release infrastructure into an unsupported state. Please fix forward
any potential problems that occur downstream and loop me into the
discussions so we can improve the release procedures in the future.
Change-Id: I8706c3d74fe0474d34a99c5cbbb8e9a88b586cdd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329902
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Kevin Chisholm <kevinjchisholm@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
First of we apply the wanted lints etc we prefer.
This includes but isn't limited to using types (i.e. no "var") and
being explicit about creation (i.e. no missing "new").
Change-Id: I516bccdac9760221ea5311af4567466bb4a65c77
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341960
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Previously we would encode the type of the value returned in `async`
functions as the field `futureValueType` on `FunctionNode`. For all
other kinds of functions, such as `sync`, `sync*`, and `async*`, that
field would be null. This CL renames `futureValueType` into
`emittedVAlueType`, and for functions of kinds `async`, `sync*`, and
`async*` that is expected to be the type of values emitted via
`return` or `yield` statements. For `sync` functions that field is
supposed to contain `null`.
In response to https://github.com/dart-lang/sdk/issues/54159
TEST=existing
Change-Id: I1efdbcc4e75d150f5618c7ca50cfe49a0e54fce6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341662
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
General approach: Find all scopes for an offset,
then pick "the right one".
This still leaves a few offsets where we can't pick 1 scope in the
(non-outline) dills in the out directory though.
More thorough testing will follow.
TEST=ci
Change-Id: I66448498e07aa03f720733bcaf167bbfa30bca2f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338840
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
With a aot snapshot generated before this CL like this:
```
out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot \
pkg/front_end/tool/_fasta/compile.dart
```
and then moved to `pkg/front_end/tool/_fasta/compile.org`,
then benchmarks run like
```
rm /path/to/other/checkout/pkg/front_end/tool/_fasta/compile.dart.dill ; \
rm pkg/front_end/tool/_fasta/compile.aot ; \
out/ReleaseX64/dart-sdk/bin/dart compile aot-snapshot \
pkg/front_end/tool/_fasta/compile.dart && \
out/ReleaseX64/dart pkg/front_end/tool/benchmarker.dart \
--iterations=50 \
--snapshot=pkg/front_end/tool/_fasta/compile.org \
--snapshot=pkg/front_end/tool/_fasta/compile.aot \
--arguments=/path/to/other/checkout/pkg/front_end/tool/_fasta/compile.dart \
--filesize=/path/to/other/checkout/pkg/front_end/tool/_fasta/compile.dart.dill
```
(The other checkout is at 8b01baab71)
I get this:
```
Generated: [...]/pkg/front_end/tool/_fasta/compile.aot
Will now run 50 iterations with 2 snapshots.
......................................................................................................
Comparing snapshot 1 with snapshot 2
msec task-clock:u: -1.9077% +/- 0.5801% (-74.85 +/- 22.76)
page-faults:u: -2.6477% +/- 0.0391% (-2579.42 +/- 38.12)
cycles:u: -2.0459% +/- 0.6018% (-324680453.54 +/- 95498561.25)
instructions:u: -1.4202% +/- 0.0003% (-286466291.62 +/- 55229.41)
branch-misses:u: -3.0746% +/- 2.3469% (-1904933.80 +/- 1454106.83)
seconds time elapsed: -1.9144% +/- 0.5791% (-0.08 +/- 0.02)
seconds user: -1.8955% +/- 0.6479% (-0.07 +/- 0.02)
Scavenge( new space) goes from 56 to 55
Notice combined GC time goes from 948 ms to 925 ms (notice only 1 run each).
```
So `instructions:u` being the most stable says a reduction of 1.42%,
time is in that range too (-1.9077% +/- 0.5801%), although in both
cases some of it is likely the number of new space GCs going from
56 to 55.
Change-Id: I0422af966f1902c50caa366cc2ad2cd7553c06d4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333501
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This updates the handling of member access on extension type receivers
to use the added `nonTypeVariableBound` and the `hasNonObjectMemberAccess`
properties.
The `nonTypeVariableBound` replaces the `resolveTypeParameterType`,
updated to taking the nullablity into account when going through
type variable bounds.
Change-Id: Ia2eb115c208350cdf011948177b15ebbc984fcac
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333540
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This CL introduces an alternative way to calculate scopes for
expression evaluations. Currently the previous method is kept as well.
What this does is that it:
* Finds all nodes that match the offset and uri. (Ideally there's only
one, but that's not always the case --- it's the case for less than
60% of cases in the test added actually).
* Calculate the scope along the way.
* Return the scopes of all the found nodes that offset.
A test that asks for ~all file offsets in the dill files in the sdk and
compares the result with the scope the binary serialization computes is
added.
A single point can't always be found (for all dills in the sdk
only ~58.93% returns a single result), but for each query the wanted
scope is among the results returned.
For the non-outline dills in the sdk, between ~87.93% and ~94.52% of
the results are either a single result or multiple results with the
same actual scope in all of them.
Note that the test asks for ~all offsets, not just "debuggable" or
"stopable" offsets (which will likely vary depending on the vm/web
backend etc) --- likely the percentage will be higher for those points
though.
When this returns multiple results one can likely be picked by the
client based on information it has about names of variables in scope
etc.
Note that the test is rather slow, on my machine with the platforms
available there it makes 3,908,181 queries in ~3.5 minutes.
(Which corresponds to roughly 18,610 per second or under 0.06 ms per
query on average though, so it doesn't seem like a concert for actually
using it.)
Change-Id: I40b5360fcd935c70629543737e89a787de36ca16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332204
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Expressions missing offsets were:
- LogicalExpression
- ConditionalExpression
- Not
- BlockExpression
- Instantiation
- TypedefTearOff*
* I'm not sure how TypedefTearOff is actually being used, I don't see reference to it in the VM runtime. Unless the CFE lowers it before the VM gets it.
I also added a test on `binary.md` that ensures all expressions include a file offset in their serialized format. This can be expanded to statements if offsets are added to the remaining statement nodes without offsets.
TEST=Added binary_md_git_test.dart to ensure all expressions contain offset data going forward.
Change-Id: Ieaf80545f388b209f76be44db86ef07e80c8ad66
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331540
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This flag used to be used for field promotion (to ensure that lowered
late fields are promotable, provided that they are private and final
and don't have a name that conflicts with something else
non-promotable). However, as of
https://dart-review.googlesource.com/c/sdk/+/330168, the logic for
determining when a Procedure is promotable now operates solely by
checking for all the conditions that prevent promotability. Lowered
late fields are now promotable because there is no reason for them not
to be.
Change-Id: I15982acef6fe8c46334fb859306bca1417a2ca64
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331207
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This create a stub for combined member signatures from multiple
inherited non-extension type members and adds these to the
extension type declaration.
A sealed [TypeDeclaration] superclass is added to [Class] and
[ExtensionTypeDeclaration] to support accessing the enclosing type
declaration from a [Member].
TEST=existing
Change-Id: Ic01535d27a14187d37b00868e7e90fe73558b051
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331181
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This adds the representation field of an extension type declaration
as an abstract getter in the ExtensionTypeDeclaraiton marking it as
a ProcedureStubKind.RepresentationField
These are never used as interface targets and are therefore skipped
in the type flow analysis.
TEST=existing
Change-Id: Ie645e63e0995a31895e985a2025dccb1476d16bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330782
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This adds a list of `Procedure`s to `ExtensionTypeDeclaration`. This is
meant to model representation fields and combined member signatures
computed from inherited non-extension type members.
These are not meant to be handled by the backends. The combined
member signature can be the interface target of an `InstanceInvocation`
expression but will always have a `.memberSignatureOrigin` value from
one of the original class members.
TEST=existing
Change-Id: I87768ed75a3c7126b0a30f8ccf06e46678c56db6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330301
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This change adds propagation of closure values to TFA.
For now, inferred closure values are used only when they are
constant (tear-off of a static method or a constructor).
Arbitrary closures can now be referenced from unrelated
members via closure-id metadata.
In addition, this change fixes an incorrect stack trace when
an implicit closure (tear-off) was propagated and its call was
inlined. Inlining interval was not recorded because of the missing
source position of a call to a target method within implicit closure.
TEST=pkg/vm/testcases/transformations/type_flow/transformer/closures.dart
Issue: https://github.com/dart-lang/sdk/issues/39692
Change-Id: I3590da91b6057e0b55a8614382dba1bbcc267b39
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/325447
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
This renames ExtensionType.typeErasure and adds it to DartType. This also fixes the extension type erasure for when extension types are used in the arguments of an extension type.
DartType.extensionTypeErasure can be used by backends to easily
access the type without extension types for any type.
TEST=pkg/kernel/test/extension_type_erasure_test.dart
Change-Id: Ia49d273ed85111e3ae822720860a3e0be5ea0252
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329960
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Please prefer not to revert this change. Any tests that fail are release
blockers and need to be approved and urgently fixed forward. Dart 3.2
has already been cut and the version number must be updated. It is
acceptable for rolls to be blocked until the release blockers have been
resolved as P0 issues.
Remove needless version number comment from experimental_features to
remove duplicated information and simplify version updates.
Update dartdoc to a version that supports 3.3.
Change-Id: I1a19aa86e185c99e61374665f18cf24c498935a5
Tested: CQ
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329588
Commit-Queue: Slava Egorov <vegorov@google.com>
Auto-Submit: Jonas Termansen <sortie@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Remove needless version number comment from experimental_features to
remove duplicated information and simplify version updates.
Tested: CQ
Change-Id: I864bfc44070136406e95fdaf4d83f491b2c95943
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329460
Reviewed-by: Alexander Thomas <athom@google.com>
Dart2JS uses the file offset on these nodes to create JS source maps. We want to maintain these file offsets across the serialization layer when we compile from dill files rather than directly from sources.
This last CL resolves all diffs observed in test files in pkg/compiler/test/inference/data.
TEST=Updating tests for all of these in fasta offsets tests.
Change-Id: If84c7542b61c8d8b894b202c68841ccfe91dafa5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/328080
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Dart2JS uses the file offset on these nodes to create JS source maps. We want to maintain these file offsets across the serialization layer when we compile from dill files rather than directly from sources.
Dart2JS tests were serializing via `--test-mode` flag and thus had incorrect source locations for some stack traces.
TEST=Updating tests for all of these in fasta offsets tests.
Change-Id: I33862462fbff84d88f8c51bdeb1efc5771cfb8b2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327160
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This CL introduces StructuralParameter and StructuralParameterType
classes. They are intended to replace TypeParameter and
TypeParameterType respectively where those were used as type
parameters defined by FunctionTypes. Previously, type parameters of
FunctionTypes were represented by TypeParameter objects with the
‘parent’ field set to null. By introducing StructuralParameter and
StructuralParameterType this CL unambiguously separates the two
notions of type parameters.
TEST=existing
Change-Id: Ida3feb7ad96a7b2acef55840eacba9e36bf2a3e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/312264
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Jonas Termansen