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>
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>
Martin Kustermann