Update dependency dart to v3

[renovate]

This PR contains the following updates:

Package	Update	Change
dart (source)	major	>=2.12.0 <3.0.0 -> <4.0.0

---

Release Notes

dart-lang/sdk (dart)

v3.3.4

Compare Source

This is a patch release that:

• Fixes an issue with JS interop in dart2wasm where JS interop methods that used
  the enclosing library's @JS annotation were actually using the invocation's
  enclosing library's @JS annotation. (issue #​55430).

v3.3.3

Compare Source

This is a patch release that:

• Fixes an issue where dart vm crashed when running on pre-SSE41 older CPUs on Windows (issue #​55211).

v3.3.2

Compare Source

This is a patch release that:

• Fixes an issue in the CFE that placed some structural parameter references out
  of their context in the code restored from dill files, causing crashes in the
  incremental compiler whenever it restored a typedef from dill such that the
  typedef contained a generic function type on its right-hand side (issue
  #​55158).
• Fixes an issue in the CFE that prevented redirecting factories from being
  resolved in initializers of extension types (issue #​55194).
• Fixes an issues with VM's implementation of DateTime.timeZoneName
  on Windows, which was checking whether current date is in the summer or
  standard time rather than checking if the given moment is in the summer or
  standard time (issue #​55240).

v3.3.1

Compare Source

This is a patch release that:

• Fixes an issue in dart2js where object literal constructors in interop
  extension types would fail to compile without an @JS annotation on the
  library (issue #​55057).
• Disallows certain types involving extension types from being used as the
  operand of an await expression, unless the extension type itself implements
  Future (issue #​55095).

v3.3.0

Compare Source

Language

Dart 3.3 adds extension types to the language. To use them, set your
package's [SDK constraint][language version] lower bound to 3.3 or greater
(sdk: '^3.3.0').

Extension types

An extension type wraps an existing type with a different, static-only
interface. It works in a way which is in many ways similar to a class that
contains a single final instance variable holding the wrapped object, but
without the space and time overhead of an actual wrapper object.

Extension types are introduced by extension type declarations. Each
such declaration declares a new named type (not just a new name for the
same type). It declares a representation variable whose type is the
representation type. The effect of using an extension type is that the
representation (that is, the value of the representation variable) has
the members declared by the extension type rather than the members declared
by its "own" type (the representation type). Example:

extension type Meters(int value) {
  String get label => '${value}m';
  Meters operator +(Meters other) => Meters(value + other.value);
}

void main() {
  var m = Meters(42); // Has type `Meters`.
  var m2 = m + m; // OK, type `Meters`.
  // int i = m; // Compile-time error, wrong type.
  // m.isEven; // Compile-time error, no such member.
  assert(identical(m, m.value)); // Succeeds.
}

The declaration Meters is an extension type that has representation type
int. It introduces an implicit constructor Meters(int value); and a
getter int get value. m and m.value is the very same object, but m
has type Meters and m.value has type int. The point is that m
has the members of Meters and m.value has the members of int.

Extension types are entirely static, they do not exist at run time. If o
is the value of an expression whose static type is an extension type E
with representation type R, then o is just a normal object whose
run-time type is a subtype of R, exactly like the value of an expression
of type R. Also the run-time value of E is R (for example, E == R
is true). In short: At run time, an extension type is erased to the
corresponding representation type.

A method call on an expression of an extension type is resolved at
compile-time, based on the static type of the receiver, similar to how
extension method calls work. There is no virtual or dynamic dispatch. This,
combined with no memory overhead, means that extension types are zero-cost
wrappers around their representation value.

While there is thus no performance cost to using extension types, there is
a safety cost. Since extension types are erased at compile time, run-time
type tests on values that are statically typed as an extension type will
check the type of the representation object instead, and if the type check
looks like it tests for an extension type, like is Meters, it actually
checks for the representation type, that is, it works exactly like is int
at run time. Moreover, as mentioned above, if an extension type is used as
a type argument to a generic class or function, the type variable will be
bound to the representation type at run time. For example:

void main() {
  var meters = Meters(3);

  // At run time, `Meters` is just `int`.
  print(meters is int); // Prints "true".
  print(<Meters>[] is List<int>); // Prints "true".

  // An explicit cast is allowed and succeeds as well:
  List<Meters> meterList = <int>[1, 2, 3] as List<Meters>;
  print(meterList[1].label); // Prints "2m".
}

Extension types are useful when you are willing to sacrifice some run-time
encapsulation in order to avoid the overhead of wrapping values in
instances of wrapper classes, but still want to provide a different
interface than the wrapped object. An example of that is interop, where you
may have data that are not Dart objects to begin with (for example, raw
JavaScript objects when using JavaScript interop), and you may have large
collections of objects where it's not efficient to allocate an extra object
for each element.

Other changes

• Breaking Change #​54056: The rules for private field promotion have
  been changed so that an abstract getter is considered promotable if there are
  no conflicting declarations. There are no conflicting declarations if
  there are no non-final fields, external fields, concrete getters, or
  noSuchMethod forwarding getters with the same name in the same library.
  This makes the implementation more consistent and allows
  type promotion in a few rare scenarios where it wasn't previously allowed.
  It is unlikely, but this change could cause a breakage by changing
  an inferred type in a way that breaks later code. For example:

  class A {
    int? get _field;
  }
  class B extends A {
    final int? _field;
    B(this._field);
  }
  test(A a) {
    if (a._field != null) {
      var x = a._field; // Previously had type `int?`; now has type `int`
      ...
      x = null; // Previously allowed; now causes a compile-time error.
    }
  }

  Affected code can be fixed by adding an explicit type annotation.
  For example, in the above snippet, var x can be changed to int? x.

  It's also possible that some continuous integration configurations might fail
  if they have been configured to treat warnings as errors, because the expanded
  type promotion could lead to one of the following warnings:

  • unnecessary_non_null_assertion
  • unnecessary_cast
  • invalid_null_aware_operator

  These warnings can be addressed in the usual way, by removing the unnecessary
  operation in the first two cases, or changing ?. to . in the third case.

  To learn more about other rules surrounding type promotion,
  check out the guide on Fixing type promotion failures.

Libraries

dart:core

• String.fromCharCodes now allow start and end to be after the end of
  the Iterable argument, just like skip and take does on an Iterable.

dart:ffi

• In addition to functions, @Native can now be used on fields.
• Allow taking the address of native functions and fields via
  Native.addressOf.
• The elementAt pointer arithmetic extension methods on
  core Pointer types are now deprecated.
  Migrate to the new - and + operators instead.
• The experimental and deprecated @FfiNative annotation has been removed.
  Usages should be updated to use the @Native annotation.

dart:js_interop

• Breaking Change in the representation of JS types #​52687: JS types
  like JSAny were previously represented using a custom erasure of
  @staticInterop types that were compiler-specific. They are now represented
  as extension types where their representation types are compiler-specific.
  This means that user-defined @staticInterop types that implemented JSAny
  or JSObject can no longer do so and need to use
  JSObject.fromInteropObject. Going forward, it's recommended to use extension
  types to define interop APIs. Those extension types can still implement JS
  types.
• JSArray and JSPromise generics: JSArray and JSPromise are now generic
  types whose type parameter is a subtype of JSAny?. Conversions to and from
  these types are changed to account for the type parameters of the Dart or JS
  type, respectively.
• Breaking Change in names of extensions: Some dart:js_interop extension
  members are moved to different extensions on the same type or a supertype to
  better organize the API surface. See JSAnyUtilityExtension and
  JSAnyOperatorExtension for the new extensions. This shouldn't make a
  difference unless the extension names were explicitly used.
• Add importModule to allow users to dynamically import modules using the JS
  import() expression.

dart:js_interop_unsafe

• Add has helper to make hasProperty calls more concise.

dart:typed_data

• BREAKING CHANGE (https://github.com/dart-lang/sdk/issues/53218) The
  unmodifiable view classes for typed data are deprecated. Instead of using the
  constructors for these classes to create an unmodifiable view, e.g.

  Uint8List data = ...
  final readOnlyView = UnmodifiableUint8ListView(data);

  use the new asUnmodifiableView() methods:

  Uint8List data = ...
  final readOnlyView = data.asUnmodifiableView();

  The reason for this change is to allow more flexibility in the implementation
  of typed data so the native and web platforms can use different strategies
  for ensuring typed data has good performance.

  The deprecated types will be removed in a future Dart version.

dart:nativewrappers

• Breaking Change #​51896: The NativeWrapperClasses are marked base so
  that none of their subtypes can be implemented. Implementing subtypes can lead
  to crashes when passing such native wrapper to a native call, as it will try
  to unwrap a native field that doesn't exist.

Tools

Dart command line

• The dart create command now uses v3 of package:lints,
  including multiple new recommended lints by default.
  To learn more about the updated collection of lints,
  check out the package:lints 3.0.0 changelog entry.

DevTools

• Updated DevTools to version 2.31.1 from 2.28.1.
  To learn more, check out the release notes for versions
  2.29.0, 2.30.0,
  and 2.31.0.

Wasm compiler (dart2wasm)

• Breaking Change #​54004: dart:js_util, package:js, and dart:js
  are now disallowed from being imported when compiling with dart2wasm. Prefer
  using dart:js_interop and dart:js_interop_unsafe.

Development JavaScript compiler (DDC)

• Type arguments of package:js interop types are now printed as any instead
  of being omitted. This is simply a change to the textual representation of
  package js types that have type arguments. These type arguments are still
  completely ignored by the type system at runtime.

• Removed "implements <...>" text from the Chrome custom formatter display for
  Dart classes. This information provides little value and keeping it imposes an
  unnecessary maintenance cost.

Production JavaScript compiler (dart2js)

• Breaking Change #​54201:
  The Invocation that is passed to noSuchMethod will no longer have a
  minified memberName, even when dart2js is invoked with --minify.
  See #​54201 for more details.

Analyzer

• You can now suppress diagnostics in pubspec.yaml files by
  adding an # ignore: <diagnostic_id> comment.
• Invalid dart doc comment directives are now reported.
• The [flutter_style_todos][flutter_style_todos] lint now has a quick fix.

Linter

• Removed the iterable_contains_unrelated_type and
  list_remove_unrelated_type lints.
  Consider migrating to the expanded
  [collection_methods_unrelated_type][collection_methods_unrelated_type] lint.
• Removed various lints that are no longer necessary with sound null safety:
  • always_require_non_null_named_parameters
  • avoid_returning_null,
  • avoid_returning_null_for_future

v3.2.6

Compare Source

v3.2.5

Compare Source

v3.2.4

Compare Source

v3.2.3

Compare Source

This is a patch release that:

• Disallows final fields to be used in a constant context during analysis
  (issue #​54232).
• Upgrades Dart DevTools to version 2.28.4 (issue #​54213).
• Fixes new AOT snapshots in the SDK failing with SIGILL in ARM
  environments that don't support the integer division
  instructions or x86-64 environments that don't support
  SSE4.1 (issue #​54215).

v3.2.2

Compare Source

This is a patch release that:

• Adjusts the nullablity computations in the implementation of the
  upper bound algorithm in the compiler frontend (issue #​53999).

• Fixes missing closure code completion entries for function parameters
  for LSP-based editors like VS Code (issue #​54112).

v3.2.1

Compare Source

This is a patch release that:

• Fixes the left/mobile sidebar being empty on non-class pages
  in documentation generated with dart doc (issue #​54073).

• Fixes a JSON array parsing bug that causes a segmentation fault when
  flutter test is invoked with the --coverage flag
  (SDK issue #​54059, Flutter issue #​124145).

• Upgrades Dart DevTools to version 2.28.3 (issue #​54085).

v3.2.0

Compare Source

Language

Dart 3.2 adds the following features. To use them, set your package's SDK
constraint lower bound to 3.2 or greater (sdk: '^3.2.0').

• Private field promotion: In most circumstances, the types of private final
  fields can now be promoted by null checks and is tests. For example:

  class Example {
    final int? _privateField;
    Example(this._privateField);
  
    f() {
      if (_privateField != null) {
        // _privateField has now been promoted; you can use it without
        // null checking it.
        int i = _privateField; // OK
      }
    }
  }
  
  // Private field promotions also work from outside of the class:
  f(Example x) {
    if (x._privateField != null) {
      int i = x._privateField; // OK
    }
  }

  To ensure soundness, a field is not eligible for field promotion in the
  following circumstances:

  • If it's not final (because a non-final field could be changed in between the
    test and the usage, invalidating the promotion).
  • If it's overridden elsewhere in the library by a concrete getter or a
    non-final field (because an access to an overridden field might resolve at
    runtime to the overriding getter or field).
  • If it's not private (because a non-private field might be overridden
    elsewhere in the program).
  • If it has the same name as a concrete getter or a non-final field in some
    other unrelated class in the library (because a class elsewhere in the
    program might extend one of the classes and implement the other, creating an
    override relationship between them).
  • If there is a concrete class C in the library whose interface contains a
    getter with the same name, but C does not have an implementation of that
    getter (such unimplemented getters aren't safe for field promotion, because
    they are implicitly forwarded to noSuchMethod, which might not return the
    same value each time it's called).

• Breaking Change #​53167: Use a more precise split point for refutable
  patterns. Previously, in an if-case statement, if flow analysis could prove
  that the scrutinee expression was guaranteed to throw an exception, it would
  sometimes fail to propagate type promotions implied by the pattern to the
  (dead) code that follows. This change makes the type promotion behavior of
  if-case statements consistent regardless of whether the scrutinee expression
  throws an exception.

  No live code is affected by this change, but there is a small chance that the
  change in types will cause a compile-time error to appear in some dead code in
  the user's project, where no compile-time error appeared previously.

Libraries

dart:async

• Added broadcast parameter to Stream.empty constructor.

dart:cli

• Breaking change #​52121:
  • waitFor is disabled by default and slated for removal in 3.4. Attempting
    to call this function will now throw an exception. Users that still depend
    on waitFor can enable it by passing --enable_deprecated_wait_for flag
    to the VM.

dart:convert

• Breaking change #​52801:
  • Changed return types of utf8.encode() and Utf8Codec.encode() from
    List<int> to Uint8List.

dart:developer

• Deprecated the Service.getIsolateID method.
• Added getIsolateId method to Service.
• Added getObjectId method to Service.

dart:ffi

• Added the NativeCallable.isolateLocal constructor. This creates
  NativeCallables with the same functionality as Pointer.fromFunction,
  except that NativeCallable accepts closures.
• Added the NativeCallable.keepIsolateAlive method, which determines whether
  the NativeCallable keeps the isolate that created it alive.
• All NativeCallable constructors can now accept closures. Previously
  NativeCallables had the same restrictions as Pointer.fromFunction, and
  could only create callbacks for static functions.
• Breaking change #​53311: NativeCallable.nativeFunction now throws an
  error if is called after the NativeCallable has already been closed. Calls
  to close after the first are now ignored.

dart:io

• Breaking change #​53005: The headers returned by
  HttpClientResponse.headers and HttpRequest.headers no longer include
  trailing whitespace in their values.

• Breaking change #​53227: Folded headers values returned by
  HttpClientResponse.headers and HttpRequest.headers now have a space
  inserted at the fold point.

dart:isolate

• Added Isolate.packageConfigSync and Isolate.resolvePackageUriSync APIs.

dart:js_interop

• Breaking Change on JSNumber.toDart and Object.toJS:
  JSNumber.toDart is removed in favor of toDartDouble and toDartInt to
  make the type explicit. Object.toJS is also removed in favor of
  Object.toJSBox. Previously, this function would allow Dart objects to flow
  into JS unwrapped on the JS backends. Now, there's an explicit wrapper that is
  added and unwrapped via JSBoxedDartObject.toDart. Similarly,
  JSExportedDartObject is renamed to JSBoxedDartObject and the extensions
  ObjectToJSExportedDartObject and JSExportedDartObjectToObject are renamed
  to ObjectToJSBoxedDartObject and JSBoxedDartObjectToObject in order to
  avoid confusion with @JSExport.
• Type parameters in external APIs:
  Type parameters must now be bound to a static interop type or one of the
  dart:js_interop types like JSNumber when used in an external API. This
  only affects dart:js_interop classes and not package:js or other forms of
  JS interop.
• Subtyping dart:js_interop types:
  @staticInterop types can subtype only JSObject and JSAny from the set of
  JS types in dart:js_interop. Subtyping other types from dart:js_interop
  would result in confusing type errors before, so this makes it a static error.
• Global context of dart:js_interop and @staticInterop APIs:
  Static interop APIs will now use the same global context as non-static interop
  instead of globalThis to avoid a greater migration. Static interop APIs,
  either through dart:js_interop or the @staticInterop annotation, have used
  JavaScript's globalThis as the global context. This is relevant to things
  like external top-level members or external constructors, as this is the root
  context we expect those members to reside in. Historically, this was not the
  case in dart2js and DDC. We used either self or DDC's global in non-static
  interop APIs with package:js. So, static interop APIs will now use one of
  those global contexts. Functionally, this should matter in only a very small
  number of cases, like when using older browser versions. dart:js_interop's
  globalJSObject is also renamed to globalContext and returns the global
  context used in the lowerings.
• Breaking Change on Types of dart:js_interop External APIs:
  External JS interop APIs when using dart:js_interop are restricted to a set
  of allowed types. Namely, this includes the primitive types like String, JS
  types from dart:js_interop, and other static interop types (either through
  @staticInterop or extension types).
• Breaking Change on dart:js_interop isNull and isUndefined:
  null and undefined can only be discerned in the JS backends. dart2wasm
  conflates the two values and treats them both as Dart null. Therefore, these
  two helper methods should not be used on dart2wasm and will throw to avoid
  potentially erroneous code.
• Breaking Change on dart:js_interop typeofEquals and instanceof:
  Both APIs now return a bool instead of a JSBoolean. typeofEquals also
  now takes in a String instead of a JSString.
• Breaking Change on dart:js_interop JSAny and JSObject:
  These types can only be implemented, and no longer extended, by user
  @staticInterop types.
• Breaking Change on dart:js_interop JSArray.withLength:
  This API now takes in an int instead of JSNumber.

Tools

Development JavaScript compiler (DDC)

• Applications compiled by DDC will no longer add members to the native
  JavaScript Object prototype.
• Breaking change for JS interop with Symbols and BigInts:
  JavaScript Symbols and BigInts are now associated with their own
  interceptor and should not be used with package:js classes. These types were
  being intercepted with the assumption that they are a subtype of JavaScript's
  Object, but this is incorrect. This lead to erroneous behavior when using
  these types as Dart Objects. See #​53106 for more details. Use
  dart:js_interop's JSSymbol and JSBigInt with extension types to interop
  with these types.

Production JavaScript compiler (dart2js)

• Breaking change for JS interop with Symbols and BigInts:
  JavaScript Symbols and BigInts are now associated with their own
  interceptor and should not be used with package:js classes. These types were
  being intercepted with the assumption that they are a subtype of JavaScript's
  Object, but this is incorrect. This lead to erroneous behavior when using
  these types as Dart Objects. See #​53106 for more details. Use
  dart:js_interop's JSSymbol and JSBigInt with extension types to interop
  with these types.

Dart command line

• The dart create command has a new cli template
  to quickly create Dart command-line applications
  with basic argument parsing capabilities.
  To learn more about using the template,
  run dart help create.

Dart format

• Always split enum declarations containing a line comment.
• Fix regression in splitting type annotations with library prefixes.
• Support --enable-experiment command-line option to enable language
  experiments.

DevTools

• Incorporated the 2.26.1, 2.27.0, and
  2.28.1 releases of DevTools.

Linter

• Added the experimental [annotate_redeclares][annotate_redeclares] lint.
• Marked the [use_build_context_synchronously][use_build_context_synchronously] lint as stable.

Pub

• New option dart pub upgrade --tighten which will update dependencies' lower
  bounds in pubspec.yaml to match the current version.
• The commands dart pub get/add/upgrade will now show if a dependency
  changed between direct, dev and transitive dependency.
• The command dart pub upgrade no longer shows unchanged dependencies.

v3.1.5

Compare Source

This is a patch release that:

• Fixes an issue affecting Dart compiled to JavaScript running in Node.js 21. A
  change in Node.js 21 affected the Dart Web compiler runtime. This patch
  release accommodates for those changes (issue #​53810).

v3.1.4

Compare Source

This is a patch release that:

• Fixes an issue in the Dart VM, users are not being able to see
  value of variables while debugging code (issue [#​53747]).

v3.1.3

Compare Source

This is a patch release that:

• Fixes a bug in dart2js which would cause the compiler to crash when using
  @staticInterop @anonymous factory constructors with type parameters (see
  issue #​53579 for more details).

• The standalone Dart VM now exports symbols only for the Dart_* embedding API
  functions, avoiding conflicts with other DSOs loaded into the same process,
  such as shared libraries loaded through dart:ffi, that may have different
  versions of the same symbols (issue [#​53503]).

• Fixes an issue with super slow access to variables while debugging.
  The fix avoids searching static functions in the imported libraries
  as references to members are fully resolved by the front-end. (issue
  #​53541)

v3.1.2

Compare Source

This is a patch release that:

• Fixes a bug in dart2js which crashed the compiler when a typed record pattern
  was used outside the scope of a function body, such as in a field initializer.
  For example final x = { for (var (int a,) in someList) a: a };
  (issue #​53449)

• Fixes an expedient issue of users seeing an unhandled
  exception pause in the debugger, please https://github.com/dart-lang/sdk/issues/53450es/53450 for more
  details.
  The fix uses try/catch in lookupAddresses instead of
  Future error so that we don't see an unhandled exception
  pause in the debugger (issue #​53450)

v3.1.1

Compare Source

This is a patch release that:

• Fixes a bug in the parser which prevented a record pattern from containing a
  nested record pattern, where the nested record pattern uses record
  destructuring shorthand syntax, for example final ((:a, :b), c) = record;
  (issue #​53352).

v3.1.0

Compare Source

Libraries

dart:async

• Breaking change #​52334:
  • Added the interface modifier to purely abstract classes:
    MultiStreamController, StreamConsumer, StreamIterator and
    StreamTransformer. As a result, these types can only be implemented,
    not extended or mixed in.

dart:core

• Uri.base on native platforms now respects IOOverrides overriding
  current directory (#​39796).

dart:ffi

• Added the NativeCallable class, which can be used to create callbacks that
  allow native code to call into Dart code from any thread. See
  NativeCallable.listener. In future releases, NativeCallable will be
  updated with more functionality, and will become the recommended way of
  creating native callbacks for all use cases, replacing Pointer.fromFunction.

dart:io

• Breaking change #​51486:
  • Added sameSite to the Cookie class.
  • Added class SameSite.
• Breaking change #​52027: FileSystemEvent is
  sealed. This means
  that FileSystemEvent cannot be extended or implemented.
• Added a deprecation warning when Platform is instantiated.
• Added Platform.lineTerminator which exposes the character or characters
  that the operating system uses to separate lines of text, e.g.,
  "\r\n" on Windows.

dart:js_interop

• Object literal constructors:
  ObjectLiteral is removed from dart:js_interop. It's no longer needed in
  order to declare an object literal constructor with inline classes. As long as
  an external constructor has at least one named parameter, it'll be treated as
  an object literal constructor. If you want to create an object literal with no
  named members, use {}.jsify().

Other libraries

package:js

• Breaking change to @staticInterop and external extension members:
  external @staticInterop members and external extension members can no
  longer be used as tear-offs. Declare a closure or a non-external method that
  calls these members, and use that instead.
• Breaking change to @staticInterop and external extension members:
  external @staticInterop members and external extension members will
  generate slightly different JS code for methods that have optional parameters.
  Whereas before, the JS code passed in the default value for missing optionals,
  it will now pass in only the provided members. This aligns with how JS
  parameters work, where omitted parameters are actually omitted. For example,
  calling external void foo([int a, int b]) as foo(0) will now result in
  foo(0), and not foo(0, null).

Tools

DevTools

• Incorporated the 2.24.0 and 2.25.0
  releases of DevTools.

Linter

• Added new static analysis lints you can enable in
  your package's analysis_options.yaml file:
  • no_self_assignments
  • no_wildcard_variable_uses

v3.0.7

Compare Source

This is a patch release that:

• Fixes a bug in dart2js which would cause certain uses of records to lead to
  bad codegen causing a TypeError or NoSuchMethodError to be thrown
  at runtime (issue #​53001).

v3.0.6

Compare Source

This is a patch release that:

• Fixes a flow in flow analysis that causes it to sometimes ignore destructuring
  assignments (issue #​52767).
• Fixes an infinite loop in some web development compiles that include is or
  as expressions involving record types with named fields (issue #​52869).
• Fixes a memory leak in Dart analyzer's file-watching (issue #​52791).
• Fixes a memory leak of file system watcher related data structures (issue #​52793).

v3.0.5

Compare Source

This is a patch release that:

• Fixes a bad cast in the frontend which can manifest as a crash in the dart2js
  ListFactorySpecializer during Flutter web builds (issue #​52403).

v3.0.4

Compare Source

This is a patch release that:

• dart format now handles formatting nullable record types
  with no fields (dart_style issue #​1224).
• Fixes error when using records when targeting the web in development mode
  (issue #​52480).

v3.0.3

Compare Source

This is a patch release that:

• Fixes an AOT compiler crash when generating an implicit getter
  returning an unboxed record (issue #​52449).
• Fixes a situation in which variables appearing in multiple branches of an
  or-pattern might be erroneously reported as being mismatched (issue #​52373).
• Adds missing interface modifiers on the purely abstract classes
  MultiStreamController, StreamConsumer, StreamIterator and
  StreamTransformer (issue #​52334).
• Fixes an error during debugging when InternetAddress.tryParse is
  used (issue #​52423).
• Fixes a VM issue causing crashes on hot reload (issue #​126884).
• Improves linter support (issue #​4195).
• Fixes an issue in variable patterns preventing users from expressing
  a pattern match using a variable or wildcard pattern with a nullable
  record type (issue #​52439).
• Updates warnings and provide instructions for updating the Dart pub
  cache on Windows (issue #​52386).

v3.0.2

Compare Source

This is a patch release that:

• Fixes a dart2js crash when using a switch case expression on a record where
  the fields don't match the cases (issue #​52438).
• Add class modifier chips on class and mixin pages
  generated with dart doc (issue #​3392).
• Fixes a situation causing the parser to fail resulting in an infinite loop
  leading to higher memory usage (issue #​52352).
• Add clear errors when mixing inheritance in pre and post Dart 3 libraries
  (issue: #​52078).

v3.0.1

Compare Source

This is a patch release that:

• Fixes a compiler crash involving redirecting factories and FFI
  (issue #​124369).
• Fixes a dart2js crash when using a combination of local functions, generics,
  and records (issue #​51899).
• Fixes incorrect error using a void in a switch case expression
  (issue #​52191).
• Fixes a false error when using in switch case expressions when the switch
  refers to a private getter (issue #​52041).
• Prevent the use of when and as as variable names in patterns
  (issue #​52260).
• Fixes an inconsistency in type promotion between the analyzer and VM
  (issue #​52241).
• Improve performance on functions with many parameters (issue #​1212).

v3.0.0

Compare Source

Language

Dart 3.0 adds the following features. To use them, set your package's SDK
constraint lower bound to 3.0 or greater (sdk: '^3.0.0').

• Records: Records are anonymous immutable data structures that let you
  aggregate multiple values together, similar to tuples in other languages.
  With records, you can return multiple values from a function, create composite
  map keys, or use them any other place where you want to bundle a couple of
  objects together.

  For example, using a record to return two values:

  (double x, double y) geoLocation(String name) {
    if (name == 'Nairobi') {
      return (-1.2921, 36.8219);
    } else {
      ...
    }
  }

• Pattern matching: Expressions build values out of smaller pieces.
  Conversely, patterns are an expressive tool for decomposing values back into
  their constituent parts. Patterns can call getters on an object, access
  elements from a list, pull fields out of a record, etc. For example, we can
  destructure the record from the previous example like so:

  var (lat, long) = geoLocation('Nairobi');
  print('Nairobi is at $lat, $long.');

  Patterns can also be used in switch cases. There, you can destructure values
  and also test them to see if they have a certain type or value:

  switch (object) {
    case [int a]:
      print('A list with a single integer element $a');
    case ('name', _):
      print('A two-element record whose first field is "name".');
    default: print('Some other object.');
  }

  Also, as you can see, non-empty switch cases no longer need break;
  statements.

  Breaking change: Dart 3.0 interprets switch cases as patterns instead of
  constant expressions. Most constant expressions found in switch cases are
  valid patterns with the same meaning (named constants, literals, etc.). You
  may need to tweak a few constant expressions to make them valid. This only
  affects libraries that have upgraded to language version 3.0.

• Switch expressions: Switch expressions allow you to use patterns and
  multi-way branching in contexts where a statement isn't allowed:

  return TextButton(
    onPressed: _goPrevious,
    child: Text(switch (page) {
      0 => 'Exit story',
      1 => 'First page',
      _ when page == _lastPage => 'Start over',
      _ => 'Previous page',
    }),
  );

• If-case statements and elements: A new if construct that matches a value
  against a pattern and executes the then or else branch depending on whether
  the pattern matches:

  if (json case ['user', var name]) {
    print('Got user message for user $name.');
  }

  There is also a corresponding if-case element that can be used in collection
  literals.

• Sealed classes: When you mark a type sealed, the compiler ensures that
  switches on values of that type exhaustively cover every subtype. This
  enables you to program in an algebraic datatype style with the
  compile-time safety you expect:

  sealed class Amigo {}
  class Lucky extends Amigo {}
  class Dusty extends Amigo {}
  class Ned extends Amigo {}
  
  String lastName(Amigo amigo) =>
      switch (amigo) {
        Lucky _ => 'Day',
        Ned _   => 'Nederlander',
      };

  In this last example, the compiler reports an error that the switch doesn't
  cover the subclass Dusty.

• Class modifiers: New modifiers final, interface, base, and mixin
  on class and mixin declarations let you control how the type can be used.
  By default, Dart is flexible in that a single class declaration can be used as
  an interface, a superclass, or even a mixin. This flexibility can make it
  harder to evolve an API over time without breaking users. We mostly keep the
  current flexible defaults, but these new modifiers give you finer-grained
  control over how the type can be used.

  Breaking change: Class declarations from libraries that have been upgraded
  to Dart 3.0 can no longer be used as mixins by default. If you want the class
  to be usable as both a class and a mixin, mark it mixin class. If you want it to be used only as a mixin, make it a mixin
  declaration. If you haven't upgraded a class to Dart 3.0, you can still use it
  as a mixin.

• Breaking change #​50902: Dart reports a compile-time error if a
  continue statement targets a label that is not a loop (for, do and
  while statements) or a switch member. Fix this by changing the continue
  to target a valid labeled statement.

• Breaking change language/#​2357: Starting in language version 3.0,
  Dart reports a compile-time error if a colon (:) is used as the
  separator before the default value of an optional named parameter.
  Fix this by changing the colon (:) to an equal sign (=).

Libraries

General changes

• Breaking Change: Non-mixin classes in the platform libraries
  can no longer be mixed in, unless they are explicitly marked as mixin class.
  The following existing classes have been made mixin classes:
  • Iterable
  • IterableMixin (now alias for Iterable)
  • IterableBase (now alias for Iterable)
  • ListMixin
  • SetMixin
  • MapMixin
  • LinkedListEntry
  • StringConversionSink

dart:core

• Added bool.parse and bool.tryParse static methods.

• Added DateTime.timestamp() constructor to get current time as UTC.

• The type of RegExpMatch.pattern is now RegExp, not just Pattern.

• Breaking change #​49529:

  • Removed the deprecated List constructor, as it wasn't null safe.
    Use list literals (e.g. [] for an empty list or <int>[] for an empty
    typed list) or [List.filled][List.filled].
  • Removed the deprecated onError argument on [int.parse][int.parse], [double.parse][double.parse],
    and [num.parse][num.parse]. Use the [tryParse][tryParse] method instead.
  • Removed the deprecated [proxy][proxy] and [Provisional][Provisional] annotations.
    The original proxy annotation has no effect in Dart 2,
    and the Provisional type and [provisional][provisional] constant
    were only used internally during the Dart 2.0 development process.
  • Removed the deprecated [Deprecated.expires][Deprecated.expires] getter.
    Use [Deprecated.message][Deprecated.message] instead.
  • Removed the deprecated [CastError][CastError] error.
    Use [TypeError][TypeError] instead.
  • Removed the deprecated [FallThroughError][FallThroughError] error. The kind of
    fall-through previously throwing this error was made a compile-time
    error in Dart 2.0.
  • Removed the deprecated [NullThrownError][NullThrownError] error. This error is never
    thrown from null safe code.
  • Removed the deprecated [AbstractClassInstantiationError][AbstractClassInstantiationError] error. It was made
    a compile-time error to call the constructor of an abstract class in Dart 2.0.
  • Removed the deprecated [CyclicInitializationError][CyclicInitializationError]. Cyclic dependencies are
    no longer detected at runtime in null safe code. Such code will fail in other
    ways instead, possibly with a StackOverflowError.
  • Removed the deprecated [NoSuchMethodError][NoSuchMethodError] default constructor.
    Use the [NoSuchMethodError.withInvocation][NoSuchMethodError.withInvocation] named constructor instead.
  • Removed the deprecated [BidirectionalIterator][BidirectionalIterator] class.
    Existing bidirectional iterators can still work, they just don't have
    a shared supertype locking them to a specific name for moving backwards.

• Breaking change when migrating code to Dart 3.0:
  Some changes to platform libraries only affect code when that code is migrated
  to language version 3.0.

  • The Function type can no longer be implemented, extended or mixed in.
    Since Dart 2.0 writing implements Function has been allowed
    for backwards compatibility, but it has not had any effect.
    In Dart 3.0, the Function type is final and cannot be subtyped,
    preventing code from mistakenly assuming it works.

  • The following declarations can only be implemented, not extended:

    • Comparable
    • Exception
    • Iterator
    • Pattern
    • Match
    • RegExp
    • RegExpMatch
    • StackTrace
    • StringSink

    None of these declarations contained any implementation to inherit,
    and are marked as interface to signify that they are only intended
    as interfaces.

  • The following declarations can no longer be implemented or extended:

    • MapEntry
    • OutOfMemoryError
    • StackOverflowError
    • Expando
    • WeakReference
    • Finalizer

    The MapEntry value class is restricted to enable later optimizations.
    The remaining classes are tightly coupled to the platform and not
    intended to be subclassed or implemented.

dart:async

• Added extension member wait on iterables and 2-9 tuples of futures.

• Breaking change #​49529:

  • Removed the deprecated [DeferredLibrary][DeferredLibrary] class.
    Use the [deferred as][deferred as] import syntax instead.

dart:collection

• Added extension members nonNulls, firstOrNull, lastOrNull,
  singleOrNull, elementAtOrNull and indexed on Iterables.
  Also exported from dart:core.

• Deprecated the HasNextIterator class ([#​50883][]).

• Breaking change when migrating code to Dart 3.0:
  Some changes to platform libraries only affect code when it is migrated
  to language version 3.0.

  • The following interface can no longer be extended, only implemented:
    • Queue
  • The following implementation classes can no longer be implemented:
    • LinkedList
    • LinkedListEntry
  • The following implementation classes can no longer be implemented
    or extended:
    • HasNextIterator (Also deprecated.)
    • `HashMap

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.

[renovate]

⚠ Artifact update problem

Renovate failed to update an artifact related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

• any of the package files in this branch needs updating, or
• the branch becomes conflicted, or
• you click the rebase/retry checkbox if found above, or
• you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: pubspec.lock

Command failed: flutter pub get --no-precompile
pubspec.yaml has no lower-bound SDK constraint.
You should edit pubspec.yaml to contain an SDK constraint:

environment:
  sdk: '^3.2.0'

See https://dart.dev/go/sdk-constraint

[renovate]

Renovate Ignore Notification

Because you closed this PR without merging, Renovate will ignore this update. You will not get PRs for any future 3.x releases. But if you manually upgrade to 3.x then Renovate will re-enable minor and patch updates automatically.

If you accidentally closed this PR, or if you changed your mind: rename this PR to get a fresh replacement PR.