But not the identical, because introspection is async.
Change-Id: I245db88449379cd5eeb563f37fa022461b94ad81
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332624
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
For now only during the types phase, but I think this is extendable
to the declarations phase, in a follow-up CLs.
Change-Id: Ib436cba3e821e84bea498b40703f40533e545f6f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332166
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The analyzer used to crash when there's a non-serializable constant enum.
The issue was that we would not resolve any of its arguments if we find that it's non-serializable.
This change resolves the enum arguments, regardless.
Fixes https://github.com/dart-lang/sdk/issues/53793
Bug: https://github.com/dart-lang/sdk/issues/53793
Change-Id: I67508a9d76cce385533c963dabf7a20d9559d9ef
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331747
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Previously, the logic for enabling and disabling language features in
flow analysis and type inference tests relied on setters in the
`Harness` class that (a) were mostly unmatched with getters, and (b)
were almost exclusively used in just a single one direction
(e.g. `Harness.legacy` defaulted to `true`, so it was only ever set to
`false`).
Cleaned up so that there are explicit `enable` and `disable` methods
in the `Harness` class to cover all the use cases.
Change-Id: I5ccc8585f803fec634cad1472395ea0d135c87c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332064
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Update the type inference algorithm so that `FlowAnalysis.propertyGet`
is appropriately called when analyzing code that refers to the
representation variable of an extension type.
Flow analysis requires an arbitrary `Object` to represent the property
in question; this is later passed to
`OperationsCfe.isPropertyPromotable`. We use the synthetic
"representation field" (which is actually a `Procedure`) for this
purpose
(`ExtensionTypeRepresentationAccessTarget.representationField`).
Representation variables are considered promotable if they are public
(see
https://github.com/dart-lang/language/pull/3411). `OperationsCfe.isPropertyPromotable`
can tell if the representation variable is public by checking the name
of the synthetic representation field.
Fixes#53439.
Bug: https://github.com/dart-lang/sdk/issues/53439
Change-Id: I8f7ff8fcd8e5a43de419b8441951b52a555fda1a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332480
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
TEST=Existing tests covers.
Change-Id: I161eefdc28c74f63ba1ee926800a01eea03d9930
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331960
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
1. Add `Object` and `Map` to the very short list of names that are
unminified in the app.
2. Tweak test to avoid testing minified name.
Change-Id: Ide0cedc2950b5392eb6963403a48c0f89cd1b50a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332368
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Can't repro the failure locally this time, but my feeling is that maybe the overlay is being applied before the refactor starts. This adds pumpEventQueue to allow the refactor to start before sending the overlay change.
Change-Id: I8078b4cfe000d4155b965a384dbf116ef176fd48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332208
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Ensures there is no dependency on modifying the native JavaScript
Object prototype by preventing modifications when running browser
tests.
Change-Id: Ifb22018736f90b339b9c60bbab095fb3e1c483e1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/320842
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
- Remove unused Map in source map emitter logic.
- Buffer output writing for both JS and source maps. Previously we were only buffering the source map writes.
During local compilations of a large program combined these amount to a >100MB improvement in memory usage.
Change-Id: I633c2f81aa28744e30c6a706bb3927423b38a6e0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331361
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This reverts commit 3c6ceb851a.
Reason for revert: This breaks flutter tests - running dart fix in the flutter_svg package adds a flutter_svg: any dependency line to pubspec.yaml.
Original change's description:
> Add a pass to dart fix for pubspec changes
>
> Fixes#48997
>
> Change-Id: I543a550247920e121837f2bc6c75b5c1acecc670
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331740
> Commit-Queue: Keerti Parthasarathy <keertip@google.com>
> Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Change-Id: I38a234b558d03c6c5c6c00f9ea55db7e1fbc7a89
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332171
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
The original code here called getResolvedLibrary() and then _fixErrorsInLibrary which meant if it was invoked in a part file it would do nothing (it found no resolved library) and in a container file it would also fix the part file (because _fixErrorsInLibrary enumerates the units).
This fix splits _fixErrorsInLibrary in two so it can fix libraries and units and calls the unit version from the LSP Fix All command.
Fixes https://github.com/Dart-Code/Dart-Code/issues/4813
Change-Id: Iea72c572b6e442f6846f5ba823194b30142606db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332242
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Keerti Parthasarathy <keertip@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
If we have constant type arguments include them
into the type.
This CL also expands IL tests framework with the
capability to match CompileTypes.
TEST=vm/dart/regress_53817_il_test
Bug: https://github.com/dart-lang/sdk/issues/53817
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-product-x64-try,vm-aot-linux-release-arm64-try,vm-aot-linux-release-simarm_x64-try,vm-aot-obfuscate-linux-release-x64-try
Change-Id: I48722b002d9cd436dbc8ca3c9afbefa124f18996
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331900
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Currently we have to ask users to run TFA from source
(which requires a lot of dances with figuring out
command line and checking out Dart SDK).
However statistics printing does not impose any runtime
overhead (as opposed for example to kPrintTimings
which tracks timings) so it can be runtime configurable.
Inspired by https://github.com/flutter/flutter/issues/136529
TEST=tested manually
Change-Id: Ie496d6babb1e8cbbbb9a665b14656ea334a2eeed
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331881
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
This add support for inherited combined member signatures, both from
source and from dill.
Change-Id: I163f2b30c3242ba98692d7e9b52ef93fd0d6a903
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332201
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This add a common sealed superclass TypeDeclarationType for
ExtensionType and InterfaceType and uses it to add a common
asInstanceOf method to ClassHierarchy.
Change-Id: I7294e41069b063305c3bd4e384ff90614a3936a6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331981
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Bools from environment such as `dart.library.js_util` are represented as unknown bools. They currently produce a `NON_BOOL_CONDITION` error when used in if statements in const lists, which is not the behaviour we want.
This CL marks iterables with these unknown bools in if statements as unknown and avoids other calculations like `==` upstream.
Bug: https://github.com/dart-lang/sdk/issues/53363, https://github.com/dart-lang/sdk/issues/51607
Change-Id: Ibd3e6dbc6a507c93516bc2782d59d0e1e452f17d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326261
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@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>
If the user attempts to promote a property, and their language version
does not permit field promotion, the "why not promoted" logic now
checks whether the language version is the sole reason for the failure
in property promotion. In other words, it checks whether the property
would have been promotable *if* field promotion had been enabled. If
it would, then the context message displayed to the user explains that
the property did not promote because field promotion is not supported
by the current language version.
However, if there is some secondary reason why the property failed to
promote (in other words, if the property would not have been
promotable even if field promotion had been enabled), then the context
message now favors the secondary reason.
Rationale: imagine a user is maintaining a package that doesn't yet
support SDK version 3.2, and that package contains some property
that's non-promotable both because the language version is prior to
3.2 *and* for some other reason (e.g., because the property isn't a
private field). It would be quite frustrating if the user saw a
context message suggesting that the property would be promotable in
SDK 3.2, and then went to a lot of effort to bump their minimum SDK
version, only to discover *after* the bump that the property is still
not promotable.
In the process of making this change, I discovered that the CFE
doesn't support field promotion in patch files. This is because patch
files aren't listed in `SourceLoader.sourceLibraryBuilders`, so the
logic in the `FieldPromotability` is never invoked for those
files. Since patch files are an artifact of SDK development, and will
never be used by end users, it doesn't seem worth going to extra
effort to add this support. However, I've taken care to make sure that
the "why not promoted" logic recovers gracefully in patch files (by
simply not generating a context message).
Change-Id: I6c0d1c0f4b8a7690f6f775408cb5e857b2dd7b03
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330241
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Lasse Nielsen <lrn@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 change includes:
- Removal of deprecated methods and constants
- Removal of dependency on package:expect for testing, instead copying
over the minimal amount of functionality needed for testing from
package:expect into pkg/vm_service/test/common/expect.dart
- Removal of classes and interfaces that are now found in
package:vm_service_interface
Change-Id: I21c2d228e615f97e64dd98b6512bf2e533916454
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331760
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
The first test being compiled on a batch compiler pays for the cost of
the batch compiler startup, meaning it is more likely to time out, e.g.
see https://github.com/dart-lang/sdk/issues/53672.
E.g via
`tools/test.py '--progress=status' --report --time --write-results --write-logs --clean-exit -ncfe-strong-linux service/next_...`
I get output like this:
```
0:00:37.713771 - fasta - fasta-none release_x64/service/next_through_simple_linear_test/service
0:00:37.682524 - fasta - fasta-none release_x64/service/next_through_for_loop_with_break_and_continue_test/dds
0:00:36.805734 - fasta - fasta-none release_x64/service/next_through_create_list_and_map_test/service
0:00:36.589329 - fasta - fasta-none release_x64/service/next_through_simple_linear_2_test/dds
0:00:36.586428 - fasta - fasta-none release_x64/service/next_through_simple_linear_2_test/service
0:00:36.518832 - fasta - fasta-none release_x64/service/next_through_for_each_loop_test/dds
0:00:36.407107 - fasta - fasta-none release_x64/service/next_through_create_list_and_map_test/dds
0:00:36.259945 - fasta - fasta-none release_x64/service/next_through_for_each_loop_test/service
0:00:36.211573 - fasta - fasta-none release_x64/service/next_through_call_on_field_in_class_test/service
0:00:36.189456 - fasta - fasta-none release_x64/service/next_through_call_on_field_in_class_test/dds
0:00:35.974007 - fasta - fasta-none release_x64/service/next_through_for_loop_with_break_and_continue_test/service
0:00:35.921138 - fasta - fasta-none release_x64/service/next_through_simple_linear_test/dds
0:00:09.690812 - fasta - fasta-none release_x64/service/next_through_multi_catch_test/service
0:00:09.562068 - fasta - fasta-none release_x64/service/async_next_test/service
0:00:09.530882 - fasta - fasta-none release_x64/service/next_through_operator_bracket_test/dds
0:00:09.407169 - fasta - fasta-none release_x64/service/next_through_function_expression_test/dds
0:00:09.366673 - fasta - fasta-none release_x64/service/next_through_multi_catch_test/dds
0:00:09.327895 - fasta - fasta-none release_x64/service/next_through_function_expression_test/service
0:00:09.303926 - fasta - fasta-none release_x64/service/next_through_await_for_test/service
0:00:09.236295 - fasta - fasta-none release_x64/service/next_through_simple_async_with_returns_test/dds
```
where the first 12 (the really slow ones) each is the first test being
run on that particular batch compiler, where they both pay for the
startup cost of the batch compiler (~12 seconds on my machine when
launching 12 simultaneously which is the default on my machine -- it's
probably more on the bots) and for the jit not having warmed up yet:
E.g. the first test compiles in ~22 seconds, the second in ~9 seconds,
the third in ~6 seconds on my machine (again with 12 simultaneous runs).
To make it less likely that the first compile times out this CL adds
some extra time allowance for the first run after the bulk compiler is
started. For now it's 30 seconds, but it can be adjusted if needed.
Longer term we should probably start a batch compilation test by
aot-compilng the batch compiler (which, at least currently,
doesn't support asserts
(https://github.com/dart-lang/sdk/issues/53343)
which is unfortunate).
I'll leave that for a future CL.
Bug: https://github.com/dart-lang/sdk/issues/53672
Change-Id: Id3427223c46c1e7a34b401097a3f7d5f1321ad93
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332220
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: William Hesse <whesse@google.com>
After further review the slight increase in memory usage is minimal and worth the improvement in runtime for each phase.
The new indices follow the same format as before, we assign each entity an index when it is registered into the entity map. However these new indices are only used by the entity maps and not as part of the serialization format for those entities. The index only exists to make look ups faster in the "map". As such, I've made the field private to prevent/discourage outside use of it.
Change-Id: I7a7c20a2dd51b01d2390bb4401545821a1014832
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331360
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This instance of service_extension_router has been hooked into DDS seperately. The vm_service and DDS tests still worked with the integration.
There will still be some iteration and discussion to be had, but I'd like to get this up as the initial version.
Bug: https://github.com/dart-lang/sdk/issues/53300
Change-Id: Ic72b770a61b2fc61fbd7c4b47ff8996a90f78665
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331820
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Dan Chevalier <danchevalier@google.com>
New option will only include diffs in the "main" output unit for the provided builds. Only sub-library entities have an output unit. Libraries do not have an output unit because there is no code associated with the library itself and a single library's contents can be spread across multiple output units.
Mutually exclusive with the 'package-only' flag because that one only prints libraries and 'main-only' includes no libraries.
Change-Id: I4d5abe54daa8e09d892dd2e2fc2b840f0705ad86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332120
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Revisions updated by `dart tools/rev_sdk_deps.dart`.
dartdoc (f7e9b17..53da3e1):
53da3e1d 2023-10-23 dependabot[bot] Bump actions/checkout from 4.1.0 to 4.1.1 (#3544)
62d5469d 2023-10-23 Sam Rawlins Support extension types in sidebars and categories (#3537)
69abd0f0 2023-10-22 Sam Rawlins Refactor file-gathering logic (#3539)
e9c61d1d 2023-10-22 Sam Rawlins Convert some late final fields to getters in Accessor, Annotation, Constructor (#3534)
adcdc8b7 2023-10-20 Parker Lougheed Update package:lints to v3 (#3542)
41f02622 2023-10-19 Sam Rawlins Greatly simplify ModelCommentReference (#3541)
50e4b679 2023-10-19 Sam Rawlins Remove use of NodeLocator2 (#3538)
b2de813c 2023-10-19 Sam Rawlins Remove support for deprecated leading new in comment references (#3529)
b350c688 2023-10-19 Sam Rawlins Bump to 7.0.1 (#3540)
5256e2fb 2023-10-19 Sam Rawlins Remove unused warnings (#3533)
lints (975c687..2cf8403):
2cf8403 2023-10-23 Devon Carew add no_wildcard_variable_uses; rev to a new major version (#165)
7b0f556 2023-10-23 Parker Lougheed Remove mention of no_wildcard_variable_uses from changelog (#164)
matcher (356e5f6..7512f80):
7512f80 2023-10-23 Michael Goderbauer Specify language in neverCalled docs for nicer formatting in docs (#230)
protobuf (050c162..3528fad):
3528fad 2023-10-24 Ömer Sinan Ağacan Use `setRange` when copying output chunks to the final buffer in `CodedBufferWriter` (#887)
tools (15cc9c7..da6bb18):
da6bb18 2023-10-24 Elias Yishak Enum + event constructors added for doctor events (#178)
e3dd149 2023-10-24 Elias Yishak Use futures list internally to manage send events (#184)
webdev (1bd434b..6e324af):
6e324afb 2023-10-24 Ben Konyi Add dependency on `package:vm_service_interface` (#2262)
8429a79f 2023-10-20 Elliott Brooks Only notify chatroom when daily stable testing fails (#2259)
3463d169 2023-10-19 Elliott Brooks Remove Chrome 115 extension error (#2258)
fdebc06e 2023-10-19 Elliott Brooks Reset Webdev to 3.2.0-wip after release (#2260)
9cffb896 2023-10-19 Elliott Brooks Reset DWDS to 22.1.0-wip after release (#2256)
07c70c6c 2023-10-19 Elliott Brooks Prepare Webdev for release to 3.1.0 (#2255)
Change-Id: Ieae3aadcc804a270867d7935b702987cf1f6d51c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332060
Reviewed-by: Elias Yishak <eliasyishak@google.com>
Commit-Queue: Devon Carew <devoncarew@google.com>
Both VM and DWDS populate isGetter now so we don't need to check this internal field.
There are existing tests verifying this behaviour.
Change-Id: Ia0f0d74167c718ec66a692523c1f255d63eed654
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330784
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
This adds a check that scripts exist before we create a sourceReference to assume we can download them.
I don't have a good way to test this (in the Dart SDK) because this never happens for Dart - we can always download the scripts. However this code is triggered in Flutter because of https://github.com/flutter/flutter/issues/128880 - we can't find the source so we will try to set it up for downloading.
Fixing that would avoid the need for this change (and make the behaviour more consistent with Dart), but in the meantime I think it's better that we don't produce sourceReferences for sources that don't exist.
Change-Id: I4de3f6e87fe3ff867a1ff7e6d3a5d79f7bf9fa1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330780
Reviewed-by: Helin Shiah <helinx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
I know this is just an unpublished tool, but enabling the expanded analysis at least makes the development experience consistent with other packages within `/pkg`.
Change-Id: Id4daf75cf37042662e3ab3c75dc4c4f856fd4099
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329864
Auto-Submit: Parker Lougheed <parlough@gmail.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
During this test, sometimes the refactor would complete before the overlay modification was processed, which means we don't get the expected failure response.
This isn't a server bug because the results are still consistent (and clients should discard any responses if a file was modified since the request was sent). This test was to ensure we handled the obvious cases of this in case the client did not handle it.
The fix is to artificially slow down the refactor to ensure the overlay change has time to execute before we check for consistency at the end.
Change-Id: I5697a73d7ca6dd7115dc6c0e87b8a93ba3cd533b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331940
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This brings in ~18 new commits:
c559fe5273..050c1620a9
Change-Id: I72fddb8feae2d794c890b4ada87b170f493738f3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331743
Reviewed-by: Ömer Ağacan <omersa@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Devon Carew <devoncarew@google.com>
When a field is declared in a mixin, the front end creates a synthetic
getter in the mixin application class that gets the value of the mixed
in field. So if a piece of code accesses the mixed in field through
the mixin application class rather than through the mixin directly,
the resolved member is the synthetic getter rather than a field.
In order to ensure that the field remains promotable even if it is
accessed through the mixin application, the logic in
`OperationsCfe.isPropertyPromotable` needs to be changed so that it
doesn't treat these synthetic getters as non-promotable. The old logic
was essentially this:
1. If the property is not private, it's not promotable.
2. Otherwise, if the property is listed in
`FieldNonPromotabilityInfo.fieldNameInfo`, it's not
promotable. (This happens either if the property is not promotable
for an intrinsic reason, such as being a non-final field or a
concrete getter, or if it has the same name as a non-promotable
property elsewhere in the library).
3. Otherwise, if the property is a getter that was lowered from an
abstract field, it's promotable.
4. Otherwise, if the property is a getter that was lowered from a late
field, it's promotable.
5. Otherwise, the property isn't promotable. (This was intended to
cover the case where the property is an abstract getter
declaration).
(Although conditions 3 and 4 were tested first, since they are more
efficient to test).
It turns out that once conditions 1-2 have been ruled out, the
property must have been declared as a method (which is being torn
off), a private abstract getter, or a (possibly abstract) non-external
private final field. Of these three possibilities, only the last is
promotable. So this can be simplified to:
(conditions 1-2 as above)
3. Otherwise, if the property is a method tear-off, it's not promotable.
4. Otherwise, if the property is an abstract getter, it's not promotable.
5. Otherwise, the property is promotable.
This makes the logic easier to follow, since conditions 1-4 are now
all reasons for non-promotability (rather than a mix of promotability
and non-promotability reasons). It also conveniently addresses the
problem with fields accessed through mixin applications, since they
aren't excluded by any of conditions 1-4.
(We still test conditions 3 and 4 first, since they are more efficient
to test.)
Fixes#53742.
Fixes#53617.
Fixes#53436.
Change-Id: I64df269c2a4a0714f9be239d832b61f4fb6a1a43
Bug: https://github.com/dart-lang/sdk/issues/53742
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330168
Reviewed-by: Nate Bosch <nbosch@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
- Fixes typo in CHANGELOG.md
- Reverts vm_service version bump to ^12.0.0 as it's not needed for this
breaking change
Change-Id: Ib9251dac0af4958d72fcb341490643bfe0f7a21a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331800
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
To reduce the headache associated with adding parameters to VM service
APIs, VmServiceInterface has been removed from package:vm_service and
pulled into its own dedicated package:vm_service_interface. This will
help reduce the need for major version bumps of package:vm_service,
which requires manual version bumps through >8 packages in order to make
the latest version available to flutter_tools and DevTools.
This separation of the VmService client from the interface will reduce
the frequency of major version bumps to `package:vm_service` as adding
optional parameters to existing APIs would cause implementers of the
interface to break.
package:vm_service continues to expose a copy of the contents of package:vm_service_interface to avoid breaking google3 rolls until package:dwds can migrate to package:vm_service_interface. package:vm_service will not be published until this copy is removed.
This change also includes:
- some code cleanup and modernization to both the code generator and
generated code
- >=3.0.0 SDK version requirement to allow for new language features
Change-Id: Ib1859c1b4e153fef7ee1f91e67e881bbf42652c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330500
Reviewed-by: Derek Xu <derekx@google.com>
Reviewed-by: Devon Carew <devoncarew@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Bug: b/286184681
Change-Id: Ia96e14d885a23e041a0bf96cb46976d90ec9228c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331285
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Auto-Submit: Alexander Thomas <athom@google.com>
The top level LICENSE file already covers wasm_builder and this is not
meant to be published separately from the Dart SDK right now.
Bug: b/286184681
Change-Id: Id11bdf5c4939a94e1074d94b803e3281f0d2c153
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331049
Auto-Submit: Alexander Thomas <athom@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
We recently added the ability to pass a `--write-dump-info-data=` flag to Dart2JS's emitter phase which will serialize the necessary metadata to run dump info as a standalone phase of the compiler.
This extra metadata was incurring an overhead since we were maintaining JS AST nodes longer in order to extract metadata out of them. With this change we get rid of that overhead. The nodes are only retained until they printed and then any references to them are freed.
After this change the memory usage of the emitter phase is the same with or without the `--write-dump-info-data=` flag. There is still however some additional overhead in runtime. This is of course unavoidable as we are doing extra work to serialize the data.
Change-Id: Ib45a0e1de96d41503cbd76217b841ff013ac0655
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331000
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Given the change to use serialization indexing, these classes aren't necessary anymore. We can use the base entity and J- impls directly.
Change-Id: I1074429ca7165fa1dbf740cab96a1b432cdd0a3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326500
Reviewed-by: Sigmund Cherem <sigmund@google.com>
The element map indexing system adds complexity to our element model with little benefit. Serialization already has its own indexing logic that we now reuse for entities.
Some things to note:
1) Libraries are still assigned an index. We only use that index in one place in the namer to disambiguate members. I now assign these indices as a late final field when adding the libraries to the element map.
2) The sizes of serialized files get slightly bigger since serialization indexing uses "addresses" rather than incrementing numbers for the indices. This effect is very minimal (<4MB+ for the largest programs).
3) "Late" members (constructor and generator bodies) which are created during codegen must be tracked and registered separately. Before the index was used to determine which entities were "late".
I see a very small memory improvement across all phases because of this change. There is also a small regression in runtime because the entity map queries are hash map lookups instead of list index lookups now. I think this very small regression is worth the reduced complexity in the compiler.
If we care about getting that time regression back we can add an "IndexedEntityMixin" with a late final index member that the registry would set/manage internally and would allow it to go back to tracking entities in a List. The field should be private so it would only be used for this purpose. This would only be necessary if we find the added time overhead of the map lookups to be too much.
Change-Id: Idd6d22bfc6ab61943a07feb58b35287d50e7d72e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326461
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Simplifies indices management for serialization by reusing the same indexing readers/writers for each phase. This way the caches are shared across all the phases and we can decouple the indices with any specific data read.
This fixes an issue that prevented the indices from being used in certain read/write patterns. None of our current usages of these indices exhibited this pattern but later changes I have planned do run into this issue.
This new pattern is also more resilient to sharding/parallel data files. Previously there could be collisions if two files were written in "parallel" (such as the codegen shards) and later their address spaces had to be merged. Now we do the address space merging at read time when we have full knowledge of the parallel files and can therefore avoid collisions.
Change-Id: Iff4c1461e734fc00f251d81f9fff1b9db83484d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/326460
Reviewed-by: Stephen Adams <sra@google.com>
I found the old style of tests difficult to read and even harder to
debug, so I decided to convert them. Fortunately, a small conversion
program did most of the work.
I didn't change the actual test code except in a couple of places where
the tests were failing because the test code produced diagnostics beyond
those expected for incomplete code (such as unreferenced variables).
As much as possible I kept the original pass/fail sense of the test.
There were a few tests that were failing because the expectations were
just wrong, so in those cases I allowed the test to pass with the right
expectations. I tried to verify the expectations of the tests, but I'm
sure I missed some.
Change-Id: I80b7f914e75012562d3423cc6eb242bb8be11cc1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331215
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Many tests under `pkg`, like `pkg/js_ast` and `pkg/analyzer_cli` are
meant to run as unit tests in the Dart VM. These were also being run in
dart2js and causing flakiness because they took a long time to build on
our CQ.
Locally some of these tests compile in under 5s, but we see the
compile-time vary among the bots a lot. I've observed cases close to 30s
and some that reach the 1-minute timeout cutoff. Flakiness data show
that this is happening between 5-7% of the runs, especially on linux
bots.
This CL stops running these tests on the dart2js configuration by
changing which subset of the `pkg` suite is provided to dart2js. It also
adjusts the .status file to skip a few suites for convenience on local
testing only. This allows developers locally to run `test.py -n... pkg`
without worrying about filtering out skipped suites.
Addendum: after discussions on the CL we decided not to cmpletely drop
coverage of js_ast tests on JS to ensure it can be used in browser
environments in the future. To support this we made made the tests
cheaper by removing the dependency on package:test. They will now only
be run in a single configuration, which is all we need for this purpose.
We can reevaluate and remove this if we continue to see timeouts.
Change-Id: Idf0dbdd37e412ef71ba117ec979cb1e52585c431
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330704
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Though it's still failing, the test-script integration has pretty much
finished.
```=== 298 tests passed, 40 failed ===```
Errors are mainly
```
Exhausted heap space, trying to allocate 32 bytes.
../../runtime/vm/object.cc: 2854: error: Out of memory.
```
This change requires https://crrev.com/c/4913284 and
`"fuchsia_sdk_version": "version:15.20231007.2.1",`
in DEPS.
Bug: #38752
Change-Id: I92a387f4289fce7d05d84e483560729301541c1b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330025
Commit-Queue: Zijie He <zijiehe@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
New lints added https://dart-review.googlesource.com/c/sdk/+/330997
include implicit_call_tearoffs.
Update the template to adhere to the lint.
TEST=pkg/dartdev/test/commands/create_integration_test
Change-Id: I0133748e42e713b022027bedbc1b0c9eb581536c
Cq-Include-Trybots: luci.dart.try:pkg-mac-release-try,pkg-mac-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331186
Auto-Submit: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Unfortuantely this golden test is set up to test two configurations, the
default dump-info and a experimental kernel-first dump-info. The latter
wants to reuse the same expectations to ensure the output is the same,
but it's configuration confuses how `dump_info_test.dart -g` works. If
it sees a discrepancy it will duplicate the expectation and add a new
one instead of updating the old one.
I haven't investigated the best way to fix that, but for now, this CL
remerges the expectation so that we continue to only have one copy of
the expectations.
Change-Id: I5d2781b85ae92e8e83b6a4c395a7353bcbcca17a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331321
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Auto-Submit: Sigmund Cherem <sigmund@google.com>
- In development mode (DDC) the extra null safety errors will be thrown.
- Remove extra code paths that called unsound helpers.
- Fix expectations in weak_null_safety_errors_test.dart.
Change-Id: I107c602b0ae38b13038e501564cba9b8cfc58e70
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329568
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nicholas Shahan <nshahan@google.com>
* `BlazePackageUriResolver`: Extract a part of `resolveAbsolute` into a new public method `resolveAbsolutePath`.
This is to be able to resolve a package URI into a *folder* path rather than directly getting a Source file.
* `TransformSetManager`: Make the `fromFolder` method public and also allow passing a package name rather than deducing it.
This is to be able to give it an exactly determined folder of a package and bypass its search for related packages based on a library.
Bug: b/306416070
Change-Id: I7b1eda1e5376328a7c8370f1cdeaaeac1c4cacc4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331281
Commit-Queue: Oleh Prypin <oprypin@google.com>
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
This makes some reductions in completion payload sizes:
- Don't include empty additionalTextEdits (use null, which is excluded from the payload)
- Don't set filterText if same as labels
- Reduce number of characters used in sortText
Additionally, this adds some methods that assert these rules (and previous rules) for all completion items during test runs to ensure these do not regress.
See https://github.com/dart-lang/sdk/issues/53501
Change-Id: I3b45ce3e1a79bf94c98af222c1a7cf0943920965
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331240
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
* removes stale generated TODO
* fixes test prefixing in the all tests test for cases where tests include `_test`
* adds a file ignore for test prefixes for the all tests test
Change-Id: Ie400e275300683b8f037bb6dae62aa85a3469cff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331201
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Very much a WIP but hopefully provides enough scaffolding for some dev_compiler experimentation.
Change-Id: Ic0cfe3c30b189732ee10209ff8b4b6a88ef0d37d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330995
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
