This adds support for having a final field and an external constructor
without error, assuming that the external constructor initializes the
final field. This supports the inline class with external members use
case.
Change-Id: I33b78275e967636ed0697d17f7921e9eee30401b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/279095
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This adds support for having a final field and an external constructor
without error, assuming that the external constructor initializes the
final field. This supports the inline class with external members use
case.
Change-Id: Ie297ccc39b0a0731c146f9ac0698bba3fd83bfeb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/278502
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
The representation field of an inline class is not part of the
generated code - it does not have a corresponding synthesized top-level
methods like the other inline class members. Therefore, to support
access to the representation field, a new `representationName` field
is added to `InlineClass` that holds the name by which the
representation field can be accessed.
An access to the representation field is at runtime an access of the
receiver itself. To show that the static type of the expression changes
from the inline type of the receiver to the declared representation
type, an `AsExpression` is inserted. Since this check is not needed
at runtime, this node is marked with the new `isUnchecked` flag, that
backends can use to skip the check.
TEST=pkg/front_end/testcases/inline_class/field_access.dart
Change-Id: I635af414af2ddc541352078766ce57a9d8ded601
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/277983
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This enables the front end to skip the old-style (enum-based)
exhaustiveness checking algorithm when pattern support is enabled,
because with pattern support enabled, switches on enums are required
to be exhaustive (this will be checked by the new exhaustiveness
checking algorithm).
That in turn means that in the future, when we remove support for
language versions that lack patterns support, we will be able to
remove the old-style exhaustiveness checking algorithm.
This change has a small effect on code generated by the WASM back-end
(the only back-end that uses `isExplicitlyExhaustive`): for a switch
statement that is exhaustive *and* has an unreachable `default`
clause, after testing all the cases, the WASM back-end will generate a
branch to the `default` case. Previously it would instead generate an
`unreachable` instruction. There should be no behavioural difference
because the instruction in question is unreachable in both cases.
Also, there should be negligible code size difference because the body
of the `default` case is being emitted either way.
Bug: https://github.com/dart-lang/sdk/issues/50419
Change-Id: Id6bd7d9a540cb1b4d9c3624db8ff494438276bea
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/274924
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Validates a yaml format encoding a native asset mapping, and
synthesizes a component containing a pragma with this information.
Yaml example:
```
format-version: [1,0,0]
native-assets:
linux_x64:
'package:foo/foo.dart': ['absolute', '/path/to/libfoo.so']
```
Generated format example:
```
@pragma('vm:ffi:native-assets': {
'linux_x64' : {
'package:foo/foo.dart': ['absolute', '/path/to/libfoo.so']
}
})
library;
```
TEST=pkg/vm/test/native_assets/synthesizer_test.dart
TEST=pkg/vm/test/native_assets/validator_test.dart
In a follow-up CL, we will consume the yaml from `gen_kernel`
and consume the pragma in the VM for `@FfiNative`s.
Bug: https://github.com/dart-lang/sdk/issues/49803
Change-Id: Ie8d93b38ff4406ef7485e5513807e89b2772164b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/272660
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
I've sampled (eagerly) reading the VM platform, a compilation of
dart2js, a compilation of "flutter gallery" and a compilation of a big
internal app, and reordered switch cases accordingly.
I can't measure any difference in runtime, but have a hard time
thinking it's not better.
I've included the tool that does the sampling.
Change-Id: If61c5a95265229c238020264010553f281fec49c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/267362
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When loading the sdk, a compilation of dart2js and a big internal app
without lazy loading (but with useGrowableLists: false though that
part shouldn't matter) I see these changes:
Loading the sdk: Saving ~1.17 MB Public and ~0.33 MB Private.
A total of ~1.5 MB.
Loading a compile of dart2js: Saving: ~7.0 MB Public and ~1.1 Private.
A total of ~8.1 MB.
Loading a compile of a big internal app: Saving ~74.7 MB Public and
~25.4 MB Private.
A total of ~100 MB.
Specifically, when loading a big internal app I see these changes:
Change, without lazy loading (and useGrowableLists: false):
Current memory: -122.88 MB
Peak memory: -92.16 MB
Heap: -102.4 MB / -92.16 MB
_PublicNames: -74.75 MB (2 mio+ fewer)
_PrivateNames: -25.4 MB (800,000+ fewer)
Change, with lazy loading (and useGrowableLists: false):
Current memory: +10.24 MB (yes, more).
Peak memory: +10.24 MB (yes, more).
Heap: +2.2 MB / +2.5 MB (yes, more)
_PublicNames: -0.76 MB (20,000+ fewer)
_PrivateNames: -11.3 KB (some hundred fewer)
Change-Id: I710d966aacf2ab184139a1fb7e65e12551e830ab
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/266386
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Looking at only the amount of data used by interface types after
loading a dill completely (lazy loading disabled or everything read):
Loading the sdk: Saving ~3.3 MB.
Loading a compile of a simple flutter app: Saving: ~11.6 MB.
Loading a compile of dart2js: Saving: ~18.2 MB.
Testing on a big internal app I see savings of 200+MB.
In my tests it reduces the amount of interface types by a factor of between 7 and 12.
Looking at the VMs reported memory, peak memory and heap usage, without
lazy loading for the big internal app we're talking ~200 MB savings,
with lazy loading (without loading anything) we're generally
talking a ~10MB saving (process current an peak memory,
but where the heaps total capacity was ~4 MB bigger).
https://github.com/dart-lang/sdk/issues/50161
Change-Id: Ic6601e907fb3127694f54e0865fe7c5a7057d9f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/266383
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The initializer was built in an 'inferred' rather than a 'required'
constant context, meaning that it would be encoded as a declaratively
constant literal instead of a structurally constant literal.
Closes#50132
Change-Id: I58b995d879efd2ec374b711718b63ac8f122bcfc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/262349
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Instead of relying on descriptors, we now just take in an export
map that was already precomputed for a given class. This map is
then used to create an object literal that maps property names to
their Dart targets.
Change-Id: I431cbfb3978eb41543bb46859612e13da7637e79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/261764
Reviewed-by: Riley Porter <rileyporter@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Johnni Winther