| commit | b54e38e4a9198108d3a27339da4cbaf57e7d5041 | [log] [tgz] |
|---|---|---|
| author | Konstantin Shcheglov <scheglov@google.com> | Mon Sep 01 11:37:13 2025 -0700 |
| committer | Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> | Mon Sep 01 11:37:13 2025 -0700 |
| tree | 09c62a3ff331beb660132ee5fe3d33f0b33b702c | |
| parent | 740e81905e0a12a131ef8d3af98835d6d8d68161 [diff] |
Fine. Record and match type-parameter variance in manifests. Capture declaration-site variance for generic declarations in the fine manifests and use it during matching. Previously, manifests ignored variance, so declarations that differed only by variance could be incorrectly considered equivalent (or vice versa). Including variance closes that correctness gap and prevents unstable reuse decisions. Key changes: - Encode variance on each ManifestTypeParameter (using shared.Variance) and persist it in the wire format (written before the bound). - Compare variance when matching type parameters, affecting classes, mixins, function types, and type aliases. - Consider type parameters when matching TypeAliasItem to avoid false-positive matches of otherwise identical aliases. - Switch withTypeParameters and match sites to work with TypeParameterElementImpl so variance is available everywhere. - Update the result printer to display type-parameter variance with ordinal indices. - Bump AnalysisDriver.DATA_VERSION to 531 to invalidate stale caches. Notes: - Default (implicit) covariant parameters and explicit `out` parameters are treated equivalently, ensuring stable IDs in that case. - This is an internal format change; no public API surface is altered. Rationale: Storing and matching variance makes manifest-based reuse sensitive to a semantically observable part of generic APIs. This yields more accurate incremental analysis decisions and avoids reusing results across variance-incompatible declarations. Change-Id: I397016773c2bae8b7e588dd2b5cbdee303bbfb91 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/447945 Commit-Queue: Konstantin Shcheglov <scheglov@google.com> Reviewed-by: Johnni Winther <johnniwinther@google.com>
Dart is:
Approachable: Develop with a strongly typed programming language that is consistent, concise, and offers modern language features like null safety and patterns.
Portable: Compile to ARM, x64, or RISC-V machine code for mobile, desktop, and backend. Compile to JavaScript or WebAssembly for the web.
Productive: Make changes iteratively: use hot reload to see the result instantly in your running app. Diagnose app issues using DevTools.
Dart's flexible compiler technology lets you run Dart code in different ways, depending on your target platform and goals:
Dart Native: For programs targeting devices (mobile, desktop, server, and more), Dart Native includes both a Dart VM with JIT (just-in-time) compilation and an AOT (ahead-of-time) compiler for producing machine code.
Dart Web: For programs targeting the web, Dart Web includes both a development time compiler (dartdevc) and a production time compiler (dart2js).
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Visit dart.dev to learn more about the language, tools, and to find codelabs.
Browse pub.dev for more packages and libraries contributed by the community and the Dart team.
Our API reference documentation is published at api.dart.dev, based on the stable release. (We also publish docs from our beta and dev channels, as well as from the primary development branch).
If you want to build Dart yourself, here is a guide to getting the source, preparing your machine to build the SDK, and building.
There are more documents in our repo at docs.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.
Future plans for Dart are included in the combined Dart and Flutter roadmap on the Flutter wiki.