The experimental `dart:ffi` support predates deferred loading
implementation. Any use of FFI features would lazily import `ffi.memory`
into the (fixed coded) main module.
This CL now lazily imports the `ffi.memory` module into all modules that
operate on the memory.
=> This will now allow a flutter app that is compiled with dart2wasm
in deferred loading mode to possibly defer parts of flutter
engine code that uses FFI into deferred modules.
Issue https://github.com/dart-lang/sdk/issues/56952
Change-Id: Idf821ce2dd92c36ac1be9dae24307516a1ae86d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510760
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
'canInvokeTypeEquality' was assuming that if a single case was a Type expression, then type equality should be used for the whole switch statement. This is incorrect because if a single case is a type expression but the rest are, for example, ints (as in the fixed test) then the int cases should be compared with identical while only the type expression should be compared with ==.
More importantly, the expected type of the case expression constants should be top type rather than the Type type. Top type is the union of Type and the other case type.
Switches that only include Type expressions will now use "top" type as well but in general switching on a Type expression is an antipattern we shouldn't optimize for. And the impact of not specializing the switch type to Type should be very minimal.
Fixes: https://github.com/dart-lang/sdk/issues/63476
Change-Id: Ib96172f157d8cf3093199e5127d4835e7b25011c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509920
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
When generating SSA jump instructions (HContinue and HBreak) for AST break statements, ensure that we only select labels from the target's label list that are explicitly marked as valid continue (isContinueTarget) or break (isBreakTarget) targets.
Previously, handler.labels.first was selected indiscriminately if non-empty, which caused unlabeled continue statements inside loops that had an outer break label to incorrectly generate labeled continue jumps targeting the break label.
Fixes: https://github.com/dart-lang/sdk/issues/63456
Change-Id: Ic497776141a192edb0930f4585cdaae2feecb3d5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510280
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
The lint will fire even when there is a comment in the body, such as
```dart
class C() {
this { /* comment */ }
}
```
I think this is the right behavior because I can't think of any useful
comment that wouldn't be better somewhere else, but let me know if you
disagree.
This doesn't yet have a fix, but it should.
Change-Id: Ia5ffa6b06c75a6a7400ec32a9d22209c08a9c73d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510401
Reviewed-by: Keerti Parthasarathy <keertip@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
For clients outside the library the useful property in
`FormalParameterElement.type`, not *how* this type was specified
syntactically: `void f(int a<T>())` vs. `void f(int Function<T>() a)`.
This way, we have to think about these type parameters and formal
parameters only locally, like for example about local variables - they
exist, enclosed in a fragment, but don't leak outside into the element
model of a method.
I found this while working on the augmentations: that formal parameters
have to have the same types in the introductory declaration, and in
augmentations.
Change-Id: Ie4e92ebd0cd0204c4ba80200a9497e95859cc3e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509522
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Do not expose recovery type parameter and formal parameter elements
through the public element model. Recovery fragments are still needed
internally to link augmentation chains with mismatched shapes, but they
should not change the effective arity or callable signature of the
declaration being augmented.
Filter fragments marked as originating from another enclosing fragment
when computing executable formal parameters, executable type parameters,
and instance type parameters. This keeps function types, class arity,
and constructor or method signatures based on the real declaration
rather than on synthetic recovery elements introduced for invalid
augmentations.
Change-Id: I455a8a18bc07cdae30006754e069d687659aab1d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510182
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
This changes to handling of default value tokens on primary constructor fields to eager read the token of the fragment. This avoid leaking the token when field type inference isn't needed for the declared field.
Change-Id: I1cd7a2de7020bd403b843e1f0a456ab26a98e5ff
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510342
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Some recent changes to the parser looked like they should have cost
basically nothing but ended up costing a little bit anyway.
This CL marks the new functions for inlining recovering at least some of
the cost.
Change-Id: I599d557eb25bee892c8975d794618e837fec0caa
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510320
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds internal nodes for VariableStatement, VariableDeclaration, Let, and ForStatement. The prepares for separating Variable from InternalVariable and allows for the removal of Variable.asVariableDeclaration.
Change-Id: Ib0593f64b3d22ce99c187ab4af32c8dc8cbea6e9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509980
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Move another batch of analyzer tests away from offset-based
assertErrorsInCode() expectations. Put expected diagnostics and context
messages directly in the source snippets instead, including multi-file
cases that need context markers in supporting files.
This keeps each diagnostic expectation next to the code that produces
it, making the tests easier to read and less fragile when surrounding
code changes. It also removes now-unused diagnostic imports and helper
parameters that were only needed for explicit ExpectedDiagnostic lists.
Update the diagnostic expectation utilities so stripping generated
marker lines preserves the retained source lines correctly.
Change-Id: Ibe3890b9ff5e2b2e102e13e5ecc243bdf80c5f4b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509682
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Static field initializers are only run once and as such are cold code.
They should never be inlined into hot code that accesses the static
field.
Though right now `wasm-opt` will inline the static field initializers
e.g. if there's only one use of a static field (as it makes size a bit
smaller if we avoid the extra wasm function). That has the problem that
it may inline cold code into hot code. That hot code in return then gets
big and may not be allowed to be inlined into it's caller.
One can instruct binaryen to only inline functions with one caller up to
some size by passing `--one-caller-inline-max-function-size` (see [0]).
Though that can regress size.
So instead we specifically mark the function we know are cold to not be
inlined, namely static field initializer functions above a certain size.
This changes performance of a benchmark from [1] from
cascadeUnhoisted: 390000 us
to
cascadeUnhoisted: 138000 us
NOTE: This will cause some size regressions for e.g. e main module by
0.4-0.5% - but seems to be the right thing to do.
[0] https://github.com/WebAssembly/binaryen/issues/8619
[1] https://github.com/dart-lang/sdk/issues/63484
Change-Id: I626b8cd879a804aef638901ede190f74276d8e8b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509960
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
The front-end, dart2js, dart2wasm, ddc and analyzer bots do not need the cross-compilation or sanitizer tools, nor the VM test binaries.
Change-Id: I2f5a1041b1b29c562bace7210830e9904a31c397
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510040
Reviewed-by: Alexander Aprelev <aam@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Brian Wilkerson