The existing implementation assumed, hardcoded, that the compilation
environment had an entry for any string of the form `dart.library.`+X,
with a value of either `"true"` or `""`.
This did not match the runtime behavior of the standalone VM,
which allows non-constant access to the compilation environment.
Changed to only have entries with value `"true"` for libraries
which exist.
This changes the value of `bool.hasEnvironment` or a
`String.fromEnvironment` or `bool.fromEnvironment` with a
non-default `defaultValue`.
The existing behavior was that `bool.hasEnvironment` was always true,
and that the other constructors ignored the `defaultValue`,
so most likely such tests or `defaultValues` aren't used anyway.
Fixes#53815
Bug: https://dartbug.com/53815
Change-Id: I995bb34b5ab04b39a8a588d6a59c0027a0fe855c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331261
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
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>
This CL optimizes how CFE et al presubmits are run.
In the examples below we'll that it takes the presubmit time from 31+
to ~13 seconds, from 31+ to ~20 seconds and from 30+ to ~19 seconds on
a few simple cases and from 76+ to ~27 seconds in a case where files in
both _fe_analyzer_shared, front_end, frontend_server and kernel are
changed.
Before this CL, if there was changes in both front_end and
frontend_server for instance it would run one smoke-test for each.
They would each technically only test things in their own directory,
but they would do a lot of overlapping work, e.g. compiling
frontend_server also compiles front_end; the startup cost of a script
is done several times etc.
The bulk of the change in this CL is thus to only run things once.
Now, if there is a change in both front_end and frontend_server the
python presubmit will still launch a script for each, but it's just a
light-weight script that will take ~400 ms to run (on my machine) if it
decides to not do anything. What it does is that it looks at the
changed files, from that it will know which presubmits will be run and
decide which of them will actually do the work - the rest will just
exit and say "it will be tested by this other one".
Furthermore it then tries to run only the smoke tests necessary.
For instance, if you have only changed a test in front_end it will only
run the spell checker (and only for that file).
Note that this is not perfect and there can be cases where you should
get a presubmit error but wont. For instance if you remove all content
from the spellchecking dictionary file it should give you lots of
spelling mistake errors, but it won't because it won't actually run the
spell checker (as no files it should spell check was changed).
Probably you have to actively try to cheat it though, so I don't see it
as a big problem. Things will still be checked fully on the CI.
Additionally
* the generated messages will have trailing commas which speeds up
formatting of the generated files (in the cases where the
generated files will have to be checked).
* the explicit creation testing tool will do the outline of everything,
but only do the bodies of the changed files.
* building the "ast model" only compiles the outline.
Left to do:
* If only changing a single test, for instance, it will only run the
spell checker on that file, but launching the isolate its run in
still takes ~7 seconds because it loads up other stuff too. Maybe we
could have special entry points for cases where it only should run an
otherwise simple test.
* The presubmit in the sdk dir (not CFE related) doesn't do well with
many (big) changed files and testing them for formatting errors can
easily take 10+ seconds (see example below where it contributes ~5
seconds for instance). Maybe `dart format` could be made faster, or
maybe the script should test more than one file at once.
*Example runs before and after*:
Change in a single test file in front_end
=========================================
Now:
```
$ time git cl presubmit -v -f
[I2024-01-25 09:46:08,391 187077 140400494405504 presubmit_support.py] Found 1 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
Presubmit checks took 11.5s to calculate.
Python 3 presubmit checks passed.
real 0m12.772s
user 0m16.093s
sys 0m2.146s
```
Before:
```
$ time git cl presubmit -v -f
[I2024-01-25 10:07:08,519 200015 140338735470464 presubmit_support.py] Found 1 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
28.3s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 30.0s to calculate.
Python 3 presubmit checks passed.
real 0m31.396s
user 2m9.500s
sys 0m11.559s
```
So from 31+ to ~13 seconds.
---------------------------------------------------------------------
Change in a single test file and a single lib file in front_end
===============================================================
Now:
```
$ time git cl presubmit -v -f
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
15.9s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 18.0s to calculate.
Python 3 presubmit checks passed.
real 0m19.365s
user 0m33.157s
sys 0m5.049s
```
Before:
```
$ time git cl presubmit -v -f
[I2024-01-25 10:08:36,277 200953 140133274818432 presubmit_support.py] Found 2 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
27.9s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 30.0s to calculate.
Python 3 presubmit checks passed.
real 0m31.311s
user 2m9.854s
sys 0m11.898s
```
So from 31+ to ~20 seconds.
---------------------------------------------------------------------
Change only the messages file in front_end (but with generated files not changing)
==================================================================================
Now:
```
$ time git cl presubmit -v -f
[I2024-01-25 09:53:02,823 190466 140548397250432 presubmit_support.py] Found 1 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
15.6s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 17.0s to calculate.
Python 3 presubmit checks passed.
real 0m18.326s
user 0m38.999s
sys 0m4.530s
```
Before:
```
$ time git cl presubmit -v -f
[I2024-01-25 10:10:04,431 201892 140717686302592 presubmit_support.py] Found 1 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
28.0s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Presubmit checks took 29.2s to calculate.
Python 3 presubmit checks passed.
real 0m30.550s
user 2m9.488s
sys 0m11.689s
```
So from 30+ to ~19 seconds.
---------------------------------------------------------------------
Change several files:
```
$ git diff --stat
pkg/_fe_analyzer_shared/lib/src/messages/codes_generated.dart | 4 ++--
pkg/_fe_analyzer_shared/lib/src/parser/listener.dart | 2 ++
pkg/front_end/lib/src/api_prototype/incremental_kernel_generator.dart | 2 ++
pkg/front_end/lib/src/base/processed_options.dart | 2 ++
pkg/front_end/messages.yaml | 2 +-
pkg/front_end/tool/dart_doctest_impl.dart | 2 ++
pkg/frontend_server/lib/compute_kernel.dart | 2 ++
pkg/kernel/lib/ast.dart | 2 ++
8 files changed, 15 insertions(+), 3 deletions(-)
```
====================
Now:
```
[I2024-01-25 09:57:53,270 193911 140320429016960 presubmit_support.py] Found 8 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py
17.8s to run CheckChangeOnCommit from [...]/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py.
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
Running [...]/sdk/pkg/frontend_server/PRESUBMIT.py
Running [...]/sdk/pkg/kernel/PRESUBMIT.py
Presubmit checks took 25.3s to calculate.
Python 3 presubmit checks passed.
real 0m26.585s
user 1m8.997s
sys 0m8.742s
```
Worth noting here is that "sdk/PRESUBMIT.py" takes 5+ seconds here
Before:
```
[I2024-01-25 10:11:39,863 203026 140202046494592 presubmit_support.py] Found 8 file(s).
Running Python 3 presubmit commit checks ...
Running [...]/sdk/PRESUBMIT.py
Running [...]/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py
14.6s to run CheckChangeOnCommit from [...]/sdk/pkg/_fe_analyzer_shared/PRESUBMIT.py.
Running [...]/sdk/pkg/front_end/PRESUBMIT.py
28.0s to run CheckChangeOnCommit from [...]/sdk/pkg/front_end/PRESUBMIT.py.
Running [...]/sdk/pkg/frontend_server/PRESUBMIT.py
20.9s to run CheckChangeOnCommit from [...]/sdk/pkg/frontend_server/PRESUBMIT.py.
Running [...]/sdk/pkg/kernel/PRESUBMIT.py
Presubmit checks took 75.6s to calculate.
Python 3 presubmit checks passed.
real 1m16.870s
user 3m48.784s
sys 0m23.689s
```
So from 76+ to ~27 seconds.
In response to https://github.com/dart-lang/sdk/issues/54665
Change-Id: I59a43f5009bba8c2fdcb5d3a843b4cb408499214
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/348301
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: 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>
This change prevents `TODO` comments in pkg/kernel from showing up in
Visual Studio Code's "problems" view, which makes it much easier to
see errors, warnings, and lints in that view.
With this change, Visual Studio Code now treats `TODO` comments the
same in `pkg/kernel` as they are treated in `pkg/_fe_analyzer_shared`,
`pkg/front_end`, and `pkg/analyzer`.
Change-Id: Ifeff026b9cf5ef13c8b1a4382a82441175165374
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/338589
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Chloe Stefantsova