A FieldEntity is used as the entity for generating the setter of an
instance field (when a check is required), and as the entity for the
initializer expression for a static or top-level field.
I think it is a bit clearer to have a separate method for each case
rather than one method with conditional paths.
Change-Id: I32e63c3f3566a63e3d38315cab17d613f006405e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253562
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
When launched as a snapshot, the initial compile is slower than the existing pub approach because of a process start time of around 500 ms. When launched as a compiled executable, initial compile times are the same as the existing pub approach. Once launched, experimental results show times to produce a kernel file of at worst 1.5-2x faster than pub's solution and at best 10x faster than pub's solution. The typical workflow of making changes and recompiling results in an average of a 5x speedup with respect to pub's implementation.
Because compiler instances use a lot of memory, there is a limit on the number of active compilers that the resident server will keep alive, and will actively bring instances down when this limit is exceeded. If the user was previously compiling a given project during the lifespan of a ResidentFrontendServer and its compiler is taken down between requests, a new compiler instance will be allocated for the request. Performance is still between 1.5x-5x faster for this case when compared to pub's compile times.
Change-Id: If9ee1ecc71d660d34faf23381c764dc11d6a5902
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252001
Reviewed-by: Siva Annamalai <asiva@google.com>
Reviewed-by: Jake Macdonald <jakemac@google.com>
Commit-Queue: Michael Richards <msrichards@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
This reverts commit a5fda59219.
Reason for revert: breaks calling extension setters with `?.`, see b/241059207
Original change's description:
> [cfe] Use `void` for let-expressions for extension property set
>
> This pipes the expression type for a generated property setter, such
> that synthesized variables in let expressions created for the generated
> setter expression are typed correctly.
>
> Before this change a let variable created for an extension property set
> would use the value type even though the extension property setter is
> method with a void return type.
>
> Change-Id: I1e7d31eaf1410bb06d55e2845403865e0c7af452
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252742
> Commit-Queue: Johnni Winther <johnniwinther@google.com>
> Reviewed-by: Aske Simon Christensen <askesc@google.com>
TBR=johnniwinther@google.com,askesc@google.com
Change-Id: Iaafd12833939cbd38e09787fcdb5a4c78a964656
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253440
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Ilya Yanok <yanok@google.com>
Reviewed-by: Ilya Yanok <yanok@google.com>
This pipes the expression type for a generated property setter, such
that synthesized variables in let expressions created for the generated
setter expression are typed correctly.
Before this change a let variable created for an extension property set
would use the value type even though the extension property setter is
method with a void return type.
Change-Id: I1e7d31eaf1410bb06d55e2845403865e0c7af452
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252742
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Deletes the outline stubber as it's not necessary on any backend.
DDC should compile the entire sources and outline dill in one step.
dart2wasm operates similarly, and so only needs the modular transformer.
dart2js moves the erasure to a global transform.
Also, this CL reverts now unnecessary plumbing that was needed for the
outline stubber.
Change-Id: Ic085c4fad5a6bdfc7d6916f7fa575c6ef9b20110
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253000
Reviewed-by: Joshua Litt <joshualitt@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The resolution of the redirecting factories should happen after the
type inference because the inference needs the original, unresolved,
representation of the program. Some areas of the CFE attempt to finish
the delayed computations, including the resolution of the redirecing
factories, before the inference phase. An example of such area is the
enum member generation. It has to happen early for proper scope
construction. At this stage we know that we can delay the resolution
of the redirecting factory invocations becuause it will be attempted a
second time later, after the inference is done.
Closes https://github.com/dart-lang/sdk/issues/49429
Change-Id: I65c1f903ce2783580785cd1ad61291c28a924937
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252943
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This is a reland of commit 206fdf148c
Original change's description:
> [cfe/ffi] Improve FFI call mismatched types compile errors
>
> This CL fixes two issues.
>
> 1. `FfiNative`s now check the Dart and native type for compatiblity.
> 2. Both `FfiNative`, `asFunction`, and `lookupFunction` check the type
> correspondence between native and Dart type with a subtype check of
> the expected Dart type and the provided Dart type. For functions,
> any return type is a subtype of a void type. This is fine for Dart,
> but not for native calls. This CL manually checks the return type
> for void.
>
> This CL does not fix the inconsistency between `asFunction` and
> `FfiNative` with regard to allowing more strict return types than
> `Object` for `Handle`s
> Issue: https://github.com/dart-lang/sdk/issues/49518
>
> Analyzer fixes in follow up CL.
>
> TEST=tests/ffi/vmspecific_static_checks_ffinative_test.dart
>
> Closes: https://github.com/dart-lang/sdk/issues/49471
> Change-Id: Ibc7bd6a1a0db59cc5fa5d755d76999fd7e9a06a4
> Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try,analyzer-mac-release-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252601
> Reviewed-by: Martin Kustermann <kustermann@google.com>
> Commit-Queue: Daco Harkes <dacoharkes@google.com>
TEST=tests/ffi/vmspecific_static_checks_ffinative_test.dart
Change-Id: Ic1efba45ae8ff2585fc67fdf63c653ce090d0337
Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try,analyzer-mac-release-try,vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252663
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This CL applies `_validateCompatibleFunctionTypes` to `FfiNative`s.
The validation is enhanced to include `Pointer<Void>` to native field
wrapper conversion.
Also, this CL explicitly checks for `void` return types to match the
previous CL CFE behavior.
Closes: https://github.com/dart-lang/sdk/issues/49412
Change-Id: I96243ac1038321febf32f5a03507c6431fdb03d6
Cq-Include-Trybots: luci.dart.try:analyzer-linux-release-try,analyzer-mac-release-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252602
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Fields in mixin applications are copies of the fields from the
mixed-in class. As such, they don't need a getter or setter in the
mixin application.
Change-Id: I62a5779355e4ec57ad4b138bc17a29e42e903f79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253021
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Moves multiple classes into their own files. Renames several classes and
the associated test classes. Moves a few of those classes (files) into
the parent directory. Converts snippets to use constructor tear-offs
rather than static method tear-offs.
Change-Id: If1aae3cc468d20ef056e650c0206fcfbf3c94f62
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/253004
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
env.dart and closure.dart have a circular dependency that is a bit
hard to break, but this is a step towards starting migrating them.
It may be worth migrating the cycle of env and closure together
in one go.
That said, the definitions moved from closure.dart to
element_map_migrated.dart (e.g. ClassDefinition) seem to match
other definitions already in the latter file
(e.g. MemberDefinition)
Change-Id: Ifa8114b992e75ec6662db702fa1dd51b31112276
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/252964
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Sigmund Cherem <sigmund@google.com>
Brian Wilkerson