Before this CL the FFI external transformation set a wrong file uri on
the created procedure when the field it came from was in a part.
Possibly this is what caused
https://github.com/flutter/flutter/issues/144176
Adding a CFE test it also surfaced there not being passed a reference.
As I recall we technically disable 'advanced invaclidation' for ffi
stuff so maybe it doesn't matter, but it was easy to add and now the
test is happy.
Tested: Existing test + CFE test added.
Change-Id: I67391654677fe103d7bc22829871db2119d251dd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/355420
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
The modular parts in package:vm/modular/** will only depend on
* package:kernel
* package:front_end
=> Only for auto-generated error code messages
=> Those error codes can be their own dart_library() in g3
Based on https://dart-review.googlesource.com/c/sdk/+/353980, with
changes:
* Exclude package:kernel from "no exports" CFE presubmit.
* Add package:vm/modular to CFE "allowed deps".
* Fix import in `front_end/tool/perf_common.dart` and various others.
Tested: no code changes, only moves.
Change-Id: I9a44ac6ee05478812a9c8af31f6c4bbcf44b7c42
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354221
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Morgan :) <davidmorgan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This adds support for generating the merged augmentation library in the
CFE. In order to get the right file offsets in the generated AST the
MacroExecutor.buildArgumentationLibrary function is extended to compute
a list of spans the describe what each segment of the generated source
code contains. These spans are used to compute the offset relation
between the intermediate augmentation libraries and the merged
augmentation libraries.
Change-Id: Ie5b9c23130da67ac874fb824b82827bfd6b88880
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/349864
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
This adds a `forErrorHandling` to the `Throw` node. This is used that the `throw` is *not* present in the source code but added to ensure
correctness and/or soundness of the generated code.
This is used for instance in the lowering for handling duplicate writes
to a late final field or for pattern assignments that don't match.
In response to https://github.com/dart-lang/sdk/issues/53519
TEST=updated ast-to-text
Change-Id: Ie103829d98fda9cd7b64e9e3d893e77d1e86d7d8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347900
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Liam Appelbe <liama@google.com>
The VM target no longer supports the `foo() native "foo";` syntax. See
final removal in [0].
Dart2Wasm has never really been using it.
* In the sdk dart2wasm uses `external` functions with
recognizion in the compiler based on the name of the method.
* JS interop is using `@JS` based mechanism.
* Wasm to Wasm interop is based on `@Native<>()` annotations.
This means that only dart2js/ddc are remaining users of the
`foo() native;` syntax (without following string).
So we can clean up some code.
[0] https://dart-review.googlesource.com/c/sdk/+/266387
Issue https://github.com/dart-lang/sdk/issues/28791
TEST=ci
Change-Id: I929789f7a1ea5ed5423b0db0c6a306406e2db2af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/351083
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Over the weekend the flutter-frontend bot started failing.
This was caused by an update on the flutter side, where a dependency
started using extension types, and revealed a bug with relinking on our
side.
This CL fixes the bug which should make the bot succeed again (as well
as, I think, fix a potential leak/failure if rejecting an advanced
invalidated incremental compilation.
I will add tests in an upcoming CL.
Change-Id: I1e73314b5ce5fe70819f921f9b176c7286b31f8a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350801
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL:
* adds empty dart:_dart2js_only and dart:_ddc_only libraries for use in
conditional imports,
* updates pkg/dart2js_runtime_metrics to use the new libraries rather
than dart:_dart2js_runtime_metrics and dart:js,
* and removes some unnecessary libraries, including VM-specific
implementations in pkg/dart2js_runtime_metrics and the DDC
implementation of dart:_dart2js_runtime_metrics.
Change-Id: I9500aa303fa5ad8aba0e1d413f69957c268f3f11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350681
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Previously we would use the value of the `nullability` getter as
the carry over nullablity for the substituted type. This CL changes
that to `declaredNullability`. The change is observable in
substituted extension types: their `nullability` is a combination
of the representation type nullability and the declared nullability,
and its value range includes `Nullability.undetermined`, which should
not be available for `ExtensionType.declaredNullability`.
The unexpected value for `ExtensionType.declaredNullability` was
detected by the assert in
`_NullabilityMarkerDetector.visitExtensionType`.
Change-Id: I38f81df57db18ec94f2f6422134c02efe6649be6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350323
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
This adds the dart:_macros library to the SDK and adds support for accessing dart:_macros from package:macros. The library is not used yet.
This change is needed as a prestep to adding the package:macros and using it in the CFE and analyzer, and needs to be rolled in as the checked in sdk before package:macros can be supported.
TEST=ci
Change-Id: Ife3ffd48527e3a196048d2ddf7387b8b7818f3a3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348680
Reviewed-by: Jake Macdonald <jakemac@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Generally the test loads a big dill thats 90+% the same content as the
previous load, then verifies it.
This CL loads smarter and verifies less.
Before this CL, locally, running
pkg/frontend_server/test/frontend_server_flutter.dart took
real 24m56.080s
user 48m42.422s
sys 1m2.360s
and the suite edition (using 4 shards in isolates) took
real 15m9.196s
user 53m41.118s
sys 1m30.045s
With this CL, locally running
pkg/frontend_server/test/frontend_server_flutter.dart takes
real 5m0.206s
user 9m23.933s
sys 0m20.984s
and the suite edition takes
real 3m24.243s
user 12m0.069s
sys 0m28.131s
On the try-bot the runtime seems to have gone from ~40 minutes
to ~20 minutes, the "compile flutter tests" step from ~30 minutes to
~10 minutes and the portion of time actually running the
dart-code that compiles, loads and verifies, from ~26 minutes
to ~7 minutes.
Change-Id: I6db225c33e1c0ee817f3880327e720446150ad7d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/347282
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds an ìsImplicitCall to DynamicInvocation which is set on
expression like `d()` where `d` has type dynamic, to distinguish
the for `d.call()`.
TEST=pkg/front_end/testcases/general/dynamic_call.dart
Change-Id: I73beb911bdb315a510c862e6d4876cf7673ec3c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/346240
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
When landing https://dart-review.googlesource.com/c/sdk/+/342400
the ddc-mac builder (but not Linux and Windows) started failing.
I could reproduce on Linux though so I'm not sure why those builders
didn't fail (nor why it wasn't caught by the try bot), either way this
fixes the issues:
* Test update: E.g. a breakpoint at the end of the scope doesn't work
because it will not be inside the (wanted) scope.
* Test update: Evalating "this" now actually works.
* Scope finding update: DDC adds sourcemapping entries for the *end* of
things so e.g. the getter "c" will have offset and offset+1 added as
source mappings. When translating from javascript position to dart
position we might pick that and thus ask for the scope of offset+1,
but nothing will be found because no node has that offset.
Here I add a fall-back saying that if we get no results we ask again
for the nearest lower offset.
Change-Id: I7e4430d9954466494b514cf51d999358483c9f8c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/345501
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
This allows using the new scope finder and facilitates expression
compilation with and in extension types.
For now the script uri is optional (and only passable in the new json
input via package:frontend_server), and only if the script uri is passed
we'll use the new scope finder.
Flutter etc should be updated to pass the new data.
Change-Id: I36eed1ea76a825e63e4c5b9ea60daf18aee39f3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/342400
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Anna Gringauze <annagrin@google.com>
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>
Chloe Stefantsova