TypeArgumentClassFinder.FindClass always returns null (because
non-null values are never stored to TypeArgumentClassFinder::klass_).
Consequently, code using TypeArgumentClassFinder
(TypeUsageInfo::PropagateTypeArguments) seems to be redundant and
can be removed, along with another utility class
TypeArgumentInstantiator.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-aot-linux-release-x64-try
Change-Id: I7bfc98e5c4d5b4d3effa639031ae4bd6dce25643
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295382
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
This is a reland of commit 7424295ce9
The differences between this reland and the original CL are: now the
Perfetto file recorder does not get built in PRODUCT builds, and it does
not get built unless the SUPPORT_PERFETTO macro is defined.
TEST=Recorded traces with the Perfetto file recorder and explored them
in Perfetto's trace viewer, CI
Original change's description:
> [VM] Begin supporting Perfetto file recorder
>
> This CL adds the `TimelineEventPerfettoFileRecorder` class, which is a
> timeline recorder that writes a trace to file in Perfetto's proto
> format. This CL supports the recording of all types of timeline events
> except flow events. Support for flow events will be added in a future
> CL.
>
> TEST=Recorded traces with the Perfetto file recorder and explored them
> in Perfetto's trace viewer, CI
>
> Change-Id: Iaa2051e536589a473c5e15f9de9bb9c251f13d38
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278942
> Reviewed-by: Ben Konyi <bkonyi@google.com>
> Commit-Queue: Derek Xu <derekx@google.com>
Change-Id: I8713f704b5fbeed5f1231012bce8a32aaf566ae4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/286020
Reviewed-by: Ben Konyi <bkonyi@google.com>
Commit-Queue: Derek Xu <derekx@google.com>
- For parameters of closurized members make sure to mark the virtual parameter as closurized where appropriate. Closurized parameters are treated as dynamic and this needs to propagate to all the virtual target's overrides. Previously only the concrete target was getting marked as closurized.
- For mixins defining an abstract member, foo, implementations of foo (either directly on the mixin target or superclasses of it) should propagate their types to the abstract foo as they are effectively overriding it. Calls to foo within the body of the mixin can only target the abstract foo with a virtual call. So that virtual target needs to reflect the types of all its overrides.
Tests have been added that capture both of these cases. The values here reflect the non-linearized algorithm but prior to these fixes the linearized algorithms showed a diff for both tests. After these changes there is no diff.
This fixes all failures referenced in b/277876666.
Change-Id: Icaca99cb6902c54f481eebdbb65cbd7cf81aa2c2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294960
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
DDC passes, dart2js and VM fail.
----
The dart2js and VM fringe-following scheme could be modified to call
`.iterator` at the `yield*` site and use the Iterator instead of the Iterable.
Calling `.iterator` at the `yield*` site would move the exception to the right place. It might also present an optimization opportunity where the call might be inlined, or the entry into the fringe-following algorithm could be made more efficient based on the type of the iterator.
Change-Id: Icfb6f7ca0b92cbeea1349ce138e469cfa707f571
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295200
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
Let me know if any of this is unclear or if there's missing information.
Of course, you might not know that until you start trying to enhance the
support, but we can also refine the doc when issues are discovered. I'm
mostly just interested in helping you get started.
Change-Id: Ib48a8ce46af7b6cc37a27508c81df03bfd2093e2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295040
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
These are params of the "library_for_all_configs" template, and I
believe they should also be params of
"library_for_all_configs_with_compiler".
Change-Id: I9fe959a98a9a1d0ebd2bea8f0959bcba4fc794ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295420
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
The "dart_maybe_product_config" and "dart_product_config" configs in
runtime/BUILD.gn have logic to avoid building PRODUCT artifacts in debug builds.
"library_for_all_configs" should account for this and include
extra_nonproduct_deps in debug builds even when conf.is_product is true.
Change-Id: I98a6e35fcb6f90b751d2c98f35c70ded04990b92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/295120
Commit-Queue: Derek Xu <derekx@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Create a compact version of StaticUse without fields that are often not provided. And intern instances of StaticUse as there are a lot of duplicates.
This should save >150MB in the emitter phase of Dart2JS.
Change-Id: I8d0d0c64bd9e8e3ffc7a86c413cc875be568c5a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/291620
Reviewed-by: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
When switching over a nullable expression, the `null` value should also
be handled for exhaustiveness.
The analyzer reports a lint for missing nulls, but the correction
producer was unable to fix the problem as it only adds missing enum
constants.
This change makes the fix producer add missing null cases.
Change-Id: I92065b36b6a370d5165e302d84391568894c5dc5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294981
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
- Rather than gating reads on URIs we've seen, gate logic on file scheme. Any URI with a 'file' scheme should be readable.
- Use unmapped URI when creating SourceFile. For providers that expand their URIS (e.g. BazelRootProvider) this will make sure we're using the more readable form rather than the prefix substituted version.
Change-Id: I89a00e48a6ed4fc83d403b34c42092fcc42a8b56
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294961
Commit-Queue: Stephen Adams <sra@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Skipping arm64 for lack of toolchain on the bots.
Disable tcmalloc on arm, where it fails to compile.
The builds are split into separate steps instead of using a shorter invocation like `--mode=debug,release --arch=ia32,x64,arm,riscv64` to avoid per-step timeouts.
Change-Id: Iccf5e6e8d91584147138ac37487560a7cc608b6f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/283121
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
This saves the space for the `_identityHashCode` method in the
dispatch table and allows customizing `identityHashCode` for classes
not in `dart:core`.
Change-Id: I829fb0f53dea1f3baf92e12079b9772ce2ff8c2a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/292820
Commit-Queue: Aske Simon Christensen <askesc@google.com>
Reviewed-by: Joshua Litt <joshualitt@google.com>
Auto-Submit: Aske Simon Christensen <askesc@google.com>
For applications that want to have arbitrary number of isolates call
into native code that may be blocking, we expose the API functions that
allows those native threads to exit an isolate before running
long/blocking code.
Without the ability to exit/re-enter isolate, one may experience
deadlocks as we have a fixed limit on the number of concurrently
executing isolates atm.
In the longer term we may find a way to do this automatically
with low overhead, see [0]. But since those API functions are quite
stable and we already expose e.g. `Dart_{Enter,Exit}Scope`, I don't
see a reason not to expose `Dart_{Enter,Exit}Isolate`.
Difference to original CL:
Do use STL synchronization primitives (as the ones in runtime/bin
are not always available in shared libraries)
[0] Issue https://github.com/dart-lang/sdk/issues/51261
Issue https://github.com/dart-lang/sdk/issues/51254
TEST=ffi{,_2}/dl_api_exit_enter_isolate_test
Change-Id: Id817e8d4edb3db35f029248d62388cbd0682001d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294980
Reviewed-by: Daco Harkes <dacoharkes@google.com>
A redirecting factory is normally encoded as something like
```
static factory •({required self::HelperClass bar = #C1}) → self::Bar
return new self::Foo::•(bar: bar);
```
which the CFE also expects to recreate its internal state when loading
a dill file.
The Finalizable transformation from FFI can change that to something
like:
```
static factory •({required self::HelperClass bar = #C1}) → self::Bar {
return block {
final synthesized self::Foo :expressionValueWrappedFinalizable = new self::Foo::•(bar: bar);
_in::reachabilityFence(bar);
} =>:expressionValueWrappedFinalizable;
}
```
though, which the CFE doesn't understand and subsequently crashes as
in https://github.com/flutter/flutter/issues/124369
This CL makes the CFE understand this transformed version,
fixing the crash.
TEST=Existing tests; added incremental compiler test.
Change-Id: I5e7a5fc6201e4419e9ec1ca69d5522d5190f1f83
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294761
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Danny Tuppeny