Perfetto gn/write_buildflag_header.py requires at least 3.9 because
it uses type hints like list[str].
Without the spec Flutter bots try to run it using Python 3.8.x which
fails.
Change-Id: I34fb038c591705220481ee8e3036a4626a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/483500
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
There is only one very small formatting change that only affects code
when "preserve trailing commas" is on. We generally leave that off in
the SDK and in google3. So this should be safe to roll in.
I'd like to publish a version of the dart_style that supports 3.12 to
pub soon, but I already merged the above chain on main, so I want to
roll it into the SDK and google3 first.
Change-Id: I21e84b7d69be300929b3919d73107939f1050727
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/483421
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Nate Bosch <nbosch@google.com>
Add ScopeContext helpers for visiting function- and method-related
declarations, and route existing visitors through them to reduce
duplicated scoping logic.
This centralizes the ordering and scopes for:
- FunctionTypeAlias
- FunctionTypedFormalParameter
- GenericFunctionType
- GenericTypeAlias
- MethodDeclaration
As part of the refactor, ResolutionVisitor now delegates these nodes to
ScopeContext and computes FunctionTypedFormalParameterElement.type from
the element’s own type parameters and formal parameters, avoiding
fragment-to-element remapping.
The generated resolver and summary reference resolver are updated to use
the new helpers while preserving their extra hooks (e.g. setting
nameScope/LinkingNodeContext, controlling body traversal, and ensuring
documentation comments are visited in the correct parameter scopes).
Change-Id: I8384e68a89f1ff0fa61fab9434e22fd9c703693f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/483363
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Primary constructors introduces the ability to use `new` in place of
a class name in a constructor. The previous changes to code completion
missed this, but this CL causes `new` to be suggested at the beginning
of a member.
Change-Id: I56ac6d3d8649e55de264f6e4f91b4c5db2e37c92
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/483322
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Adds support for `streamListen` and `streamCancel`. Service extension
events are now sent on the `Service` stream when extensions are
registered and unregistered.
Change-Id: I024e6e1fc214ee3f882463c3eed50700c27c6364
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479360
Reviewed-by: Jessy Yameogo <yjessy@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
State dumps produced by assertDriverStateString previously focused on
the file system and library context, which made it difficult to debug
why a driver was (or was not) doing work. In particular, there was no
visibility into queued file changes, pending tracker sets, or the
driver’s current priority.
Extend the state printer to include a dedicated driver/workState section
that captures the scheduler-facing view of pending work, including:
- priority files and pending file changes
- file tracker queue sizes and pending/changed file sets
- current work priority
In the future I plan adding more addFile / changeFile / removeFile
tests, and would like to get more visibility into the state.
Improve expectation failures in resolution tests by printing a pretty
diff and failing immediately, instead of dumping the entire actual
output and then running an additional equality assertion.
Change-Id: I98a97bb50b9bf6bbd85bb90039c4080a813485cc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482968
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Closes https://github.com/dart-lang/sdk/issues/62573
isA<JSExportedDartFunction>() used to just check if the object
was a function, leading to a possible runtime error if `toDart`
is called. Fixes that by introducing some helpers and moving
around some functions in the JS compilers to other internal
libraries (public members can't be added to
js_allow_interop_patch.dart). Also fixes a minor issue in dart2js
where `allowInterop`ed functions could successfully invoke
`JSExportedDartFunction.toDart`.
CoreLibraryReviewExempt: Documentation change.
Change-Id: I5a9d7c31d3143eb3fb6ebd3273a4bf06ca329479
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482967
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
This allows a great deal of linker GC resulting in a much smaller binary. The benefit multiplies for Flutter development because the Flutter tool downloads many variant copies of gen_snapshot.
out/ReleaseX64/exe.stripped/gen_snapshot -1.55M (-23.4%)
TEST=ci
Change-Id: I9f6e650f78ea52c9c6953320a669b71019403236
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482965
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Extension type primary constructor (representation) parameters must be
resolved in different name scopes depending on whether the primary
constructors are enabled for the library.
When `Feature.primary_constructors` is enabled, treat the primary
constructor as being inside the body and resolve its formal parameters
inside `withInstanceScope`. This matches the DeCo model and preserves
the pre-existing analyzer behavior.
When the feature is disabled (for example `// @dart = 3.10`), the
representation parameter list is outside the body and must be resolved
in the enclosing scope, before entering the instance scope. Previously
we when implementing primary constructors feature, we resolved it inside
the instance scope unconditionally, which would cause semantic changes
to pre-feature code. But I think this is a rare corner case.
Example of the incorrect analysis in `@dart = 3.10` mode:
extension type A(int it) {
static const String int = 'not a type';
}
Before this change, `int` was resolved to the static member `A.int`,
leading to `notAType` and an `InvalidType` for `it`. After this change,
`int` resolves to `dart:core::int` as intended for 3.10, while
primary-constructors mode continues to report the shadowing error.
Also centralize access to the library `FeatureSet` to keep scope
construction consistent.
Bug: https://github.com/dart-lang/sdk/issues/62622
Change-Id: I22912c55bf12f2dc9465bcf32e6d32f9b21a8b5c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482921
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
When an explicit initializer or assignment is turned into an initializing formal, it's possible for that to change the semantics if there are other references to the same parameter.
For example:
```dart
// Before:
class C {
int? x;
C(int? x) {
print(this.x);
this.x = x;
}
}
// After:
class C {
int? x;
C(this.x) {
print(this.x);
}
}
```
This prints "null" before and the argument value after.
The fix might even lead to invalid code:
```dart
// Before:
class C {
int? x;
int? y;
C(int? x) : y = (x = 2) {
this.x = x;
}
}
// After:
class C {
int? x;
int? y;
C(this.x) : y = (x = 2);
}
```
This becomes a compile error because `x` is final when it refers to an initializing formal in the initializer list.
It's also not enough to look for secondary writes inside the constructor:
```dart
// Before:
class C {
int? x;
Function()? closure;
C(int? x) {
closure = () {
print(x);
};
this.x = x;
}
}
// After:
class C {
int? x;
Function()? closure;
C(this.x) {
closure = () {
print(x);
};
}
}
// Given:
main() {
var c = C(1);
c.x = 2;
c.closure!();
}
```
This prints "1" before and "2" after.
I think the safest thing is to be conservative and not show the lint if there are any other references to the parameter anywhere in the constructor, even reads.
Fix#58607.
Change-Id: Ib976cd5bfc4bf44439ecd4175090dbabfe1cde16
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482985
Commit-Queue: Paul Berry <paulberry@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Drop libprotobuf dependency and update compile_perfetto_protos
to rely on externally provided protoc and protozero_plugin.
This is done because protoc does not build with our current
toolchain and fixing this build requires rolling new protobuf,
protobuf_gn and perfetto. Which also pulls more external dependencies
like abseil.
Regenerate Perfetto *.pbzero{.cc,.h}, *.dart files
TEST=ci
Change-Id: I11a32aa07e810b48ac12502e526bbaee6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482781
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This updates JS exception catching as discussed in #55481:
- Only catch JS exceptions when the exception type is `dynamic`,
`Object`, or an extension of `JSValue`. (nullable or not)
(Previously we also caught JS exceptions when the type is `Error`.)
- When the JS value caught in Wasm is `null` or `undefined`, box it as a
non-interop class. For compatibility with dart2js, this class is
copied from dart2js and has the same `toString` as the dart2js class.
- In other cases: box the JS values as `JSValue`. This means the value
can be passed as any of the interop types, and can be passed back to
JS without manual jsification.
Fixes#55481.
Issue: https://github.com/dart-lang/sdk/issues/55481
Change-Id: I23e73074729f740b90df2ca8b3c713fb39966556
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/479640
Reviewed-by: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
If we have Dart stack frame information don't give up on profiler
sample if C frame is malformed due to invalid FP. We are not
going to use C frame information anyway.
TEST=ci
Change-Id: I8da05d1397f805543b7721fa9d861a996a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482780
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
All numbers via
```
perf stat -e instructions:u out/ReleaseX64/dart-sdk/bin/dartaotruntime_product --deterministic --marker_tasks=1 --new_gen_semi_initial_size=10000 --new_gen_semi_max_size=20000 pkg/analyzer/tool/stable_analysis.aot --silent /tmp/stable_analysis_extract
```
### Update
With https://dart-review.googlesource.com/c/sdk/+/478701 having been
reverted I've rebased and this is the new numbers:
Parent CL:
42,708,904,561 instructions:u
42,705,451,731 instructions:u
42,705,714,002 instructions:u
This CL:
42,517,120,185 instructions:u
42,517,237,423 instructions:u
42,514,559,436 instructions:u
Saves ~188 mio instructions
---------
### Original commit message
At parent CL:
43,497,152,157 instructions:u
43,496,619,753 instructions:u
43,496,990,462 instructions:u
with this CL:
43,114,441,607 instructions:u
43,115,191,318 instructions:u
43,114,584,671 instructions:u
So this saves ~381 mio instructions...
Notice that metadata is used a lot more with https://dart-review.googlesource.com/c/sdk/+/478701 which cost ~900 mio instructions.
Reverting that CL I get:
42,696,057,264 instructions:u
42,698,447,840 instructions:u
42,695,543,793 instructions:u
Reverting and applying this CL I get:
42,504,068,113 instructions:u
42,503,699,054 instructions:u
42,503,965,559 instructions:u
So this still saves ~191 mio instructions.
Change-Id: Ibc8ff507c0ef043a3d04f6c952001795f04938bb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481801
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
All numbers via
```
perf stat -e instructions:u out/ReleaseX64/dart-sdk/bin/dartaotruntime_product --deterministic --marker_tasks=1 --new_gen_semi_initial_size=10000 --new_gen_semi_max_size=20000 pkg/analyzer/tool/stable_analysis.aot --silent /tmp/stable_analysis_extract
```
### Update
With https://dart-review.googlesource.com/c/sdk/+/478701 having been
reverted I've rebased and this is the new numbers:
Before:
43,147,479,541 instructions:u
43,147,488,753 instructions:u
43,147,472,393 instructions:u
After:
42,708,904,561 instructions:u
42,705,451,731 instructions:u
42,705,714,002 instructions:u
So this CL saves ~438 mio instructions.
---------
### Original commit message
Current HEAD:
44,034,141,347 instructions:u
Current HEAD and with this CL:
43,496,513,158 instructions:u
So here it saves ~537 mio instructions.
Notice that metadata is used a lot more with https://dart-review.googlesource.com/c/sdk/+/478701 which cost ~900 mio instructions.
Reverting that CL I get:
43,134,247,808 instructions:u
Reverting and applying this CL I get:
42,695,542,548 instructions:u
So this still saves ~438 mio instructions.
Change-Id: Ie658bd5618c93518ef4b7c1370e75b57d8e2087a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481700
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
ConvertToInitializingFormal can convert an initializer to an initializing formal, or an assignment statement in the body:
```dart
class C {
int x;
C(int x) {
this.x = x;
}
}
```
When converting from an assignment statement, if there are no statements left in the block, it deletes the entire function body.
Prior to this CL, it would also erroneously delete any initializers that happened to be on the constructor:
```dart
// Before:
class C {
int? x;
int? y;
C(int? x) : y = 1 {
this.x = x;
}
}
// Result of applying fix:
class C {
int? x;
int? y;
C(this.x); // Oops! Where did ": y = 1" go?
}
```
Change-Id: I5bd27e925509adc82056b71f4c96432c819bc954
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482966
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Centralize documentation comment traversal in ScopeContext so that all
declarations visit doc comments under a consistent
DocumentationCommentScope.
The new helper temporarily rebinds the doc-import scope’s inner scope to
the current name scope, assigns the comment’s nameScope, and then visits
the comment. This preserves correct resolution of identifiers referenced
from documentation comments while avoiding duplicated scope plumbing.
As part of the refactor:
- Remove per-call visitDocumentationComment overrides from ScopeContext’s
declaration visitors.
- Delete ScopeResolverVisitor’s private _visitDocumentationComment helper
and ScopeContext.withDocImportScope.
- Update all resolver call sites to route doc-comment visits through the
new ScopeContext API.
Change-Id: Iffbefb03cf5f61b61144a9f3a9cfc85b4df10491
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482981
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Removes the `_flowAnalysisInfoMap` field from the `Harness` class,
which serves as the test harness for the mini_ast used in flow
analysis testing, along with the methods `getFlowAnalysisInfo` and
`storeFlowAnalysisInfo` that did map lookups. Calls to
`getFlowAnalysisInfo` are replaced with logic that pulls the flow
analysis expression info directly from the expression analysis result,
and calls to `storeFlowAnalysisInfo` are dropped (since they are no
longer needed).
Also, the assertion is dropped from `dispatchExpression` that used to
verify that the information stored in the map matched the information
stored in the expression analysis result.
Change-Id: I6a6a69643e0345a1f5ef84f09340119b56bfed12
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482580
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Makes the following updates to the mini_ast used for flow analysis
testing:
- When visiting a `Write` node, the flow analysis expression info is
pulled directly from the analysis result of the RHS and passed to
`_visitWrite`, rather than deferring to `_visitWrite` to look it up
using `getFlowAnalysisInfo`.
- When computing the promoted type or the promotion chain of a
`Property` node, the flow analysis expression info is pulled
directly from the analysis result of the target (by
`_computeMemberAndFlowAnalysisInfo`) rather than looking it up using
`getFlowAnalysisInfo`.
- When creating the guard variable for a null-aware property access or
method call, the result of analyzing the target is passed directly
to `createNullAwareGuard`, allowing it to obtain the flow analysis
expression info directly rather than fetching it from
`getFlowAnalysisInfo`. The modified expression info for the
null-checked target is then returned directly back to the caller
using another analysis result, rather than requiring the caller to
look it up using another call to `getFlowAnalysisInfo`.
These changes pave the way for removing the `getFlowAnalysisInfo` and
`storeFlowAnalysisInfo` methods from mini_ast, along with the map they
use for storage.
Change-Id: I6a6a6964d4533c16f622f08b302a7f62c959b58f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482562
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Thread the library FeatureSet into LocalScope and FormalParameterScope
so wildcard handling can be decided directly from the active language
features.
This removes reliance on per-element `isWildcardVariable` checks (which
require digging through element/library state) and centralizes the
`wildcard_variables` gate in scope construction and mutation.
Also:
- Drop the now-unneeded nullable `Element?.isWildcardVariable` helper.
- Remove the extensions import from scope.dart and add lightweight
assertions around LocalScope inputs.
Change-Id: I3a0f2e0528464c48a0b944590eb4dcee918a12e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482982
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Introduce ScopeContext.visitEnumDeclaration and visitClassTypeAlias to
centralize the standard scoping/visitation order for these declarations,
including type-parameter scope, instance scope, and documentation
comment handling.
Refactor ResolutionVisitor, ScopeResolverVisitor, and ReferenceResolver
to use the new helpers, reducing duplicated scope plumbing and keeping
the three resolver phases consistent.
Fix enum primary-constructor formal parameters being visited outside the
body scope, which could resolve annotations and type names against the
library scope rather than enum members (for example, when static members
shadow outer names).
Change-Id: I2ea8335ac6a225a13b5498ffda0a0bcb1ac9b889
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482961
Reviewed-by: Paul Berry <paulberry@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Migrates the mini_ast used for flow analysis testing so that instead
of associating expressions with expression info objects using
`FlowAnalysis.getExpressionInfo` and
`FlowAnalysis.storeExpressionInfo`, it does so using its own private
map, which it accesses using the new methods `getFlowAnalysisInfo` and
`storeFlowAnalysisInfo`.
This paves the way for two independent arcs of work:
- Removing the `getExpressionInfo` and `storeExpressionInfo` methods
from `FlowAnalysis`.
- Simplifying mini_ast so that it tracks expression info objects using
`ExpressionTypeAnalysisResult.flowAnalysisInfo` rather than its own
private map.
A similar effort is underway for the analyzer and front_end, which
should carry the following benefits:
- It will make type analysis more performant by avoiding map lookups
- It will decrease the risk of subtle bugs when one expression is
changed into another.
Change-Id: I6a6a6964f0c41c62be21efc0fa16b22b10e85b34
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482561
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
This CL changes the `state:` field of the lint documentation records in
pkg/linter/messages.yaml from `experimental` to `stable`.
The CL https://dart-review.googlesource.com/c/sdk/+/479841 was intended
to change the status, and it did remove a paragraph from the
documentation about the lints being experimental, but it was complete in
that it did not change the `state:` fields.
Change-Id: I986dfc28dc6a6943c760cbe129ee619d8162a613
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/482785
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Slava Egorov