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>
This changes PatternForInElement to use InternalPattern. With this change InternalPattern is now detached from Pattern and used exclusively as the input to inference.
Change-Id: I62e4255a0f981784fef07ac91f283161f02e3d31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509940
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Updates the simplification of moving constat operands of comparisons to the right to correctly use the strictly swapped operand rather than the negated operand.
Also change the `flipOperands` function to a `swapped` getter to avoid confusion and be clearer that it returns a new value, rather than changing the current one. This better aligns with the Effective Dart guidelines for when to use a getter and how to name them.
TEST=pkg/cfg/testcases/simplification.dart
Change-Id: Id2c19b7cfcbc1586413251b2b9d6d54abcf590c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509840
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
When casting a getter return value that requires a covariance check, the
CFE inserts an AsExpression where both the operand type and
tested-against type are statically identical (the instantiated member
return type, e.g. Callable<void Function(num)>).
The types.dart optimizer previously assumed that because the static
types matched, the runtime type arguments must also match, and optimized
away the type-argument checks. However, in a covariance check, the
dynamic value returned is a supertype (e.g. Callable<void
Function(int)>) due to class parameter covariance.
This change safely rewrites the static operand type of a covariance check
by preserving the InterfaceType structure but using calculateBounds to
rewrite its type arguments to their upper bounds (falling back to Object?
or Object for non-interface types). This allows us to keep class-check
optimizations active while remaining sound.
TEST=tests/language/covariant/callable_class_field_getter_test.dart
Fixes https://github.com/dart-lang/sdk/issues/53091
Change-Id: Ia64ea90b1bad2f7c1dab81cc3385103507b97b3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508425
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Kevin Moore <kevmoo@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Work towards https://github.com/dart-lang/sdk/issues/63527
We will want to deprecate the `analyzer/language/strict-casts` setting,
but we first need to ship an SDK to Flutter that offers the lint rule,
before we deprecate the setting, which will cause CI to fail (like a
Dart->Flutter roll).
When the deprecation is enabled, we can also ship the automated fix.
Change-Id: I0e9651171b721577acbd416d254bca3d0324f3f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509521
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This reduces e main module by around -0.4% uncompressed
and -0.5% compressed
Value types don't have identiy, they are compared by value. As such
there's no need to have a unique int/double box for the same value -
each module can have their own box: The box identity cannot observed.
That in return means also we avoid exporting those from main module &
importing into deferred modules.
Change-Id: Ib63949b59263b7381396323210b4218662f56525
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509321
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Measured on size of e main module (baseline is we don't embed
it in application code):
* embedding before: +16.5% uncompressed / +9.1% compressed
* embedding with this CL: +4% uncompressed / +4.3% compressed
When embeddeding deferred load list information into the app
(as opposed to a separate json file) we now use a more compact
encoding.
Specifically: Instead of encoding it as an array of an array of
strings (which are module names), we encode it as an array of an
array of module ids and construct the module name from the id.
To make the array of module ids more compact we utilize the fact
that we can sort them and encode in delta encoding (i.e. instead
of absolute module ids, encode the diff between previous module
id in the list).
We put the encoded module id lists in a data section and create
`WasmArray<WasmI8>`s from them at startup. When we trigger a load
we then decode them into the list of module names.
There's more opportunity to optimize it, but it's good to do
this as a first step.
Change-Id: I293fb8879d992fc370786f6c9b258ccd27e1559b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508980
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Work towards https://github.com/dart-lang/sdk/issues/63516
I have code here to deprecate the `analyzer/language/strict-raw-types`
setting. But I disabled it, as I realized we first need to ship an SDK
to Flutter that offers the lint rule, before we deprecate the setting,
which will cause CI to fail (like a Dart->Flutter roll).
When the deprecation is enabled, we can also ship the automated fix.
Change-Id: I17d1ea9aba96063059e37891c05d4a8bd3f02737
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509063
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
When we built the added the original interactive refactors support, we supported the client telling the server which field kinds it can prompt for, so that if there were questions the client didn't support that did not have default values, the refactor could be hidden.
However, we only implemented one such refactor (Move to File) and the only field (destination URI) has a default value, so the client capabilities never have any effect.
Since we're replacing this support with the new "Interactive Forms" and don't intend to create any new refactors using the old system, this code is all redundant and therefore can be deleted.
Change-Id: Ic940dc54e325ccab05b28f496dbedee76e17e0b4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509460
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Similar to the previous CL for Add Import Prefix, this adds support for prompting for a name for "Add Constructor Name" if Interactive Forms are available.
Change-Id: I952695df03016a549345f329ac04961d7c279af1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/509380
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Konstantin Shcheglov