Flow analysis has improved and issue #40041 is resolved. These
`FutureOr<T>` conditionals are promoting to `Future<T>` or `T` and no
longer need an explicit cast.
R=lrn@google.com
Change-Id: I925db6d7f52aad54c88434ff02e1d0ae4e72278b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331206
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Auto-Submit: Nate Bosch <nbosch@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@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>
Bug: b/296994239
Change-Id: I179cc7729846885ee952d26082a1e615a46a30b9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331923
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
This test has flaked on our CI but actually it's consistently failing
because we do not represent `typedef`s in a reflective way in the VM
since switching to kernel (because they used to be desguared on kernel
level).
So this has not been working for a long time, let's remove this test.
Issue https://github.com/dart-lang/sdk/issues/44489
Change-Id: I36e8d8aee7a7736e8afc5741b01d10429ac0d7a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331941
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Slava Egorov <vegorov@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>
Change-Id: I70c593ca2b7f9ba6b7cc94886f622f4af5dd20fd
CoreLibraryReviewExempt: documentation update
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330620
Reviewed-by: Brian Quinlan <bquinlan@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Intercept all `Utf8Decoder.convert` calls to check the input type and
call the right UTF8 decoder function.
This currently only optimizes `U8List` parsing, and only the fastest
path where the input is an ASCII string. Follow-up CLs will optimize JS
typed array parsing by calling browser's UTF8 decoder and the slow paths
of non-ASCII and malformed buffers.
Results from an internal benchmark extracted from a real use case:
Before:
Parse(RunTime): 330,500 us.
After:
Parse(RunTime): 90,310 us. (-72%)
dart2js -O4 results of the same benchmark:
Parse(RunTime): 234,250 us.
Change-Id: I470697a9eb516e1e031e9b865ddb29e8f25569bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331187
Commit-Queue: Ömer Ağacan <omersa@google.com>
Reviewed-by: Jackson Gardner <jacksongardner@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>
This reverts commit 9a11fe517c.
Reason for revert: broke the build for some users.
Original change's description:
> [infra] Begin RBE Linux x64 support.
>
> Bug: b/296994239
> Change-Id: I0ddf9a1beb2996ac67b59779b8b8113432434786
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331282
> Reviewed-by: William Hesse <whesse@google.com>
> Commit-Queue: Jonas Termansen <sortie@google.com>
> Reviewed-by: Alexander Thomas <athom@google.com>
Bug: b/296994239
Change-Id: Id70259b9357790581f11f105516ff0c6c63ab1ac
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331780
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This reverts commit b657773d58.
Reason for revert: blocking Dart SDK -> Engine roll (https://github.com/flutter/flutter/issues/137054)
Original change's description:
> [typed_data] Deprecate UnmodifiableUint8ListView and friends
>
> This is the first of several steps to remove the unmodifiable views for typed data classes. The end goal is that dart2js has only one class implementing `Uint8List` so that `Uint8List` accesses can always be compiled down to JavaScript code that directly uses indexed property accesses (`a[i]`).
>
> This first step deprecates the unmodifiable view classes to help prevent their use in new code, and adds `asUnmodifiableView()` methods as a replacement for the small number of places that use the classes.
>
> The next steps (see #53785) are to remove uses of the unmodifiable view classes from the SDK. Once this is complete the classes themselves can be removed.
>
> TEST=ci
>
> Issue: #53218
> Issue: #53785
>
> Change-Id: I04d4feb0d9f1619e6eee65236e559f5e6adf2661
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/321922
> Reviewed-by: Nicholas Shahan <nshahan@google.com>
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Stephen Adams <sra@google.com>
> Reviewed-by: Alexander Markov <alexmarkov@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Reviewed-by: Ömer Ağacan <omersa@google.com>
Issue: #53218
Issue: #53785
Change-Id: I0bb042269f9ff8e5cd69619cf97b60c79ea98cbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331680
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
Bug: b/296994239
Change-Id: I0ddf9a1beb2996ac67b59779b8b8113432434786
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331282
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Thomas <athom@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>
This fixes off by one in the line number program
generation noticed when using perf-annotate.
We were not emitting the row covering last comments
and those rows were were emitting were slightly off.
TEST=profiled code and looked at perf-annotate output
Change-Id: Ia0fe2fa2c830a1be8f6a129c84af01755c19e59a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331284
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Daco Harkes <dacoharkes@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>
