This doesn't roll the latest dart_style main branch in because that has some style changes and there are other style changes still in flight. I want to roll all of those in all in one batch later.
Instead, this brings in a single commit whose parent is the current dart_style commit in the SDK. That commit contains only a fix for a crash bug when an analysis_options.yaml file contains an include pointing to a non-existent file. See:
https://github.com/dart-lang/dart_style/pull/1855
This gets the main branch in sync with the stable branch which has a cherry-pick with that same fix.
Change-Id: I97e3adec1c93175d372bb972989fe6a2860cf31f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/510222
Auto-Submit: Bob Nystrom <rnystrom@google.com>
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Alexander Thomas <athom@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>
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>
Work towards https://github.com/dart-lang/sdk/issues/59524
* avoid_private_typedef_functions - Doesn’t meet any sufficient
criteria? I think a private typedef can certainly make local code
more readable.
* one_member_abstracts - Low impact. This is maybe here for Java
developers? It encourages users to use top-level functions.
Change-Id: I829acda8af0bc2bb265553e1297cd1740761b4da
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/508681
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Adds two new getters to int for bit-counting: trailingZeroBitCount
(ctz) and oneBitCount (popcount). On native platforms they operate
on the full 64-bit two's-complement representation; on the web they
operate on the least-significant 32 bits.
Implementations:
- VM: unified C++ natives Integer_trailingZeroBitCount /
Integer_oneBitCount on _IntegerImplementation, using
Utils::CountTrailingZeros64 and Utils::CountOneBits64. The receiver
may be _Smi or _Mint at runtime.
- dart2js / DDC: clz32-based ctz and a SWAR popcount.
- dart2wasm: inlined i64.ctz and i64.popcnt intrinsics.
leadingZeroBitCount (clz) is intentionally excluded from this CL: its
result depends on the platform integer width (e.g. 1.leadingZeroBitCount
is 31 on web, 63 on native), and the same value can be derived from
the existing bitLength getter when needed.
Asm intrinsification on native architectures is intentionally left for
a separate follow-up CL.
Work towards https://github.com/dart-lang/sdk/issues/6486 (this CL
covers popcount and ctz from the bit-twiddling list; clz, rotate,
reverse, and others remain).
Work towards https://github.com/dart-lang/sdk/issues/1053 (efficient
BitSet implementation).
Bug: https://github.com/dart-lang/sdk/issues/52673
Bug: https://github.com/dart-lang/sdk/issues/38346
TEST=tests/corelib/int_bit_count_test
Change-Id: I8a5cdb5c91360478f47bbd6b9c84ca1c477aa8c7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498041
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Auto-Submit: Modestas Valauskas <valauskasmodestas@gmail.com>
Reviewed-by: Lasse Nielsen <lrn@google.com>
This CL enables the primary constructors feature by default in Dart 3.13.
The primary constructors feature is a brevity feature. There are no new semantics, but it allows us to express declarations in a less verbose way.
This feature allows one constructor and a set of instance variables to be specified in the header of a declaration.
Currently a declaration with a constructor and some fields is written as:
```dart
// Current syntax.
class Point {
int x;
int y;
Point(this.x, this.y);
}
```
With a primary constructor, we would write the above as:
```
class Point(var int x, var int y);
```
If a primary constructor needs an initializer list or a body, they can be
specified inside the class using the `this` body syntax:
```dart
class Point(var int x, var int y) {
this : assert(x >= 0) {
print('Point created at $x, $y');
}
}
```
As part of this feature, you can also use the `new` and `factory` keywords to
declare constructors in the class body without repeating the class name:
```dart
class Point {
int x, y;
// Equivalent to Point(this.x, this.y)
new(this.x, this.y);
// Equivalent to Point.origin()
new origin() : x = 0, y = 0;
// Equivalent to factory Point.clone(Point other)
factory clone(Point other) => Point(other.x, other.y);
}
```
To learn more about the feature, check out the feature specification located here: https://github.com/dart-lang/language/blob/main/accepted/future-releases/primary-constructors/feature-specification.md
Tested: Has existing language, CFE, analyzer, analysis server tests.
Bug: https://github.com/dart-lang/sdk/issues/61524
Change-Id: I296f2fcd918b87bf2a1dd00256340759866c2423
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489241
Reviewed-by: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Michael Thomsen <mit@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Kallen Tu <kallentu@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
`List.unmodifiable` and `Map.unmodifiable` is as badly typed
as `List.from` and `Map.from`, but does not have a better-typed
`.of` constructor. This adds such, to give a migration target
when deprecating the badly typed constructors.
The `Future.delayed` with no second argument is also unsafely
typed, it fails if the type argument is not nullable.
The `Future.pause` creates `Future<void>` instead.
CoreLibraryReviewExempt: No new or platform specific behavior.
Change-Id: Iba101b3dc62f412003abd501fa042aca0ce63116
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/499280
Commit-Queue: Lasse Nielsen <lrn@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
This is a reland of commit e7dbd6ba48
Original change's description:
> [dart:js_interop] Make JSFunction and JSExportedDartFunction generic
>
> Fixes https://github.com/dart-lang/sdk/issues/54557
>
> The generic type in JSExportedDartFunction corresponds to the
> static type of the function it wrapped, whereas for JSFunction,
> it's purely a descriptor of the JS function.
>
> When calling JSExportedDartFunction, a cast is now introduced
> to cast it to T.
>
> When calling isA, the type in JSExportedDartFunction is passed
> along to check that the value that is wrapped is that function
> type. Because the T in JSFunction is descriptive, e.g.
> isA<JSFunction<int Function()>>() does no such check.
>
> ____
>
> Also cleans up:
>
> - isA<JSTypedArray>() logic to use intrinsic functions
> - some expectation files to be consistent for both dart2js and ddc.
>
> CoreLibraryReviewExempt: Backend-specific library with needed reviews.
> Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
CoreLibraryReviewExempt: Reland.
Change-Id: I29d706aa4967fd80390e8cb37f8144603ec007f5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498100
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This reverts commit e7dbd6ba48.
Reason for revert: Broke flutter_analyze
Original change's description:
> [dart:js_interop] Make JSFunction and JSExportedDartFunction generic
>
> Fixes https://github.com/dart-lang/sdk/issues/54557
>
> The generic type in JSExportedDartFunction corresponds to the
> static type of the function it wrapped, whereas for JSFunction,
> it's purely a descriptor of the JS function.
>
> When calling JSExportedDartFunction, a cast is now introduced
> to cast it to T.
>
> When calling isA, the type in JSExportedDartFunction is passed
> along to check that the value that is wrapped is that function
> type. Because the T in JSFunction is descriptive, e.g.
> isA<JSFunction<int Function()>>() does no such check.
>
> ____
>
> Also cleans up:
>
> - isA<JSTypedArray>() logic to use intrinsic functions
> - some expectation files to be consistent for both dart2js and ddc.
>
> CoreLibraryReviewExempt: Backend-specific library with needed reviews.
> Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
> Reviewed-by: Lasse Nielsen <lrn@google.com>
> Commit-Queue: Srujan Gaddam <srujzs@google.com>
> Reviewed-by: Martin Kustermann <kustermann@google.com>
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: I98447c8c95906feb7f8f1a57859a24fc8e4966d6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/498080
Commit-Queue: Alexander Aprelev <aam@google.com>
Auto-Submit: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Alexander Aprelev <aam@google.com>
Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com>
Fixes https://github.com/dart-lang/sdk/issues/54557
The generic type in JSExportedDartFunction corresponds to the
static type of the function it wrapped, whereas for JSFunction,
it's purely a descriptor of the JS function.
When calling JSExportedDartFunction, a cast is now introduced
to cast it to T.
When calling isA, the type in JSExportedDartFunction is passed
along to check that the value that is wrapped is that function
type. Because the T in JSFunction is descriptive, e.g.
isA<JSFunction<int Function()>>() does no such check.
____
Also cleans up:
- isA<JSTypedArray>() logic to use intrinsic functions
- some expectation files to be consistent for both dart2js and ddc.
CoreLibraryReviewExempt: Backend-specific library with needed reviews.
Change-Id: I1a55c4386e416fa4ccabe06ac5051f41c2e2e95a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/496820
Reviewed-by: Lasse Nielsen <lrn@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Fixes https://github.com/dart-lang/sdk/issues/62948
Implement a new experimental lint `simple_directive_paths` that flags
non-minimal paths in import and export directives. This includes
redundant `./` segments, backtracking `../` that can be simplified,
and un-normalized `package:` URIs.
An associated automated fix is provided to simplify these paths.
Tests are included for both the lint and the fix, covering various
scenarios inside and outside the `lib/` directory.
Change-Id: I4375547f48cc30d5375c7bdaf699ceba312df5b3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/489700
Auto-Submit: Kevin Moore <kevmoo@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Kevin Moore <kevmoo@google.com>
Now that JS exceptions are caught as JS interop values in Dart,
we should warn users on the pitfalls of including a JS interop
type in the catch clause, and instead advise them to use `isA`
to do type-checks.
dart2wasm dry-run is updated to capture this lint.
There's also some minor wording changes in the lint guidance now
that `isA` can be executed on any value.
Change-Id: I65779951f2ff3f7dacfb915f3b105541c1f9a9b7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/483960
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Srujan Gaddam <srujzs@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>
Fixes https://github.com/dart-lang/sdk/issues/56905
Instead of just supporting isJSAny and isJSObject, we
can support isA for all objects. Depending on the static
type, we include an intrinsic _isJSAny function first in
the transformation. For fast paths for JSObjects, we also
now call an intrinsic function which has the added benefit
of now correctly returning true for objects with no prototype.
The intrinsic functions in dart2wasm need to be careful to
not treat ExternalDartReferences as JS values, so JSValue
is amended to include a field that determines if the value
is a Dart value (and caches it if not set already). JSValue
constructions are updated to pass false for this field if
we know for sure this value isn't an externalized Dart value.
CoreLibraryReviewExempt: Backend-specific function changes.
Change-Id: Ib2a6e74b4130632791375fcda9a5b85198ad64af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/478241
Commit-Queue: Srujan Gaddam <srujzs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
With `loadDeferredModule` there was no easy way for the embedder to batch module loads that were part of the same load ID. The loop happened within the wasm runtime and so the best the embedder could do was a `setTimeout(f, 0)` and collect the modules before making a request. This can lead to unintended delays though.
Instead we now pass the full list of modules to the embedder's registered loader along with an instantiator function so that the emebedder can start compiling concurrently before all the modules are done loading.
Added a changelog entry since this API is new but might be in use.
Change-Id: I4ae3a9fc28fc726909f63a1dd4ea1d98d5fc3fc0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/481360
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
Work towards https://github.com/dart-lang/sdk/issues/59514
We introduced a new Warning called NON_NULLABLE_EQUALS_PARAMETER a few releases ago. It warns when the parameter of an `operator ==` override has a nullable type:
> The parameter type of '==' operators should be non-nullable.
I didn't realize it at the time, but that new warning, plus null safety, basically replace the `avoid_null_checks_in_equality_operators` lint rule. This rule reports doing any null-check work on a nullable parameter of an `operator ==` override.
Change-Id: Ibd8139cd5804a9ccb6cc07d2187c9305a336c7cd
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467922
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Robert Nystrom