32ab547688
This CL contains several small bug fixes: - The context is only used for type inference if it is a record type with the same shape as the record literal. Previously, if the context was a record type with a different shape than the record literal, the analyzer would attempt to do an approximate match (using the context from any matching named fields, and from all the positional fields that were in common between the context and the literal). At first glance, it might seem like this would only matter for erroneous code (since record shape mismatches typically lead to compile-time errors). But if the context arises from a local variable promotion, then a mismatch doesn't lead to a compile-time error; it simply leads to a demotion. So the difference is observable for non-erroneous code. - If one of the fields is implicitly downcast from `dynamic`, the static type of the field's expression remains `dynamic`. This makes the behavior of dynamic downcasts inside field literals consistent with all other implicit dynamic downcasts. - If one of the fields is implicitly downcast from `dynamic`, the downcast is made to the greatest closure of the context. Previously, the downcast was made to the context itself, which meant that it was possible to create static types containing the unknown type, violating one of the key assumptions of the Dart type system. - If one of the fields has a static type of `dynamic`, and `dynamic` is a subtype of the greatest closure of the context (e.g. because the context is `Object?`), no dynamic downcast is performed. Previously, a dynamic downcast _was_ performed, meaning that the static type of the resulting record literal would have `dynamic` in a spot where `Object?` should be. This brings the analyzer behavior into line with the spec and the front end, with one minor exception: - When the front end uses the greatest closure of the context to implicitly downcast a field from dynamic, it uses a modified greatest closure algorithm where covariant instances of `_` are replaced with `dynamic` instead of `Object?`. The front end's behavior in this rare case doesn't agree with the spec; I'll address this in a future CL. Change-Id: Ib1ab7ee4d0f63a152480704e2c0d5332446a613c Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/350983 Reviewed-by: Bob Nystrom <rnystrom@google.com> Reviewed-by: Konstantin Shcheglov <scheglov@google.com> Commit-Queue: Paul Berry <paulberry@google.com> |
||
---|---|---|
.dart_tool | ||
.github | ||
benchmarks | ||
build | ||
docs | ||
pkg | ||
runtime | ||
samples | ||
sdk | ||
tests | ||
third_party | ||
tools | ||
utils | ||
.clang-format | ||
.gitattributes | ||
.gitconfig | ||
.gitignore | ||
.gn | ||
.mailmap | ||
.style.yapf | ||
AUTHORS | ||
BUILD.gn | ||
CHANGELOG.md | ||
codereview.settings | ||
CONTRIBUTING.md | ||
DEPS | ||
LICENSE | ||
OWNERS | ||
PATENT_GRANT | ||
PRESUBMIT.py | ||
README.dart-sdk | ||
README.md | ||
sdk.code-workspace | ||
sdk_args.gni | ||
SECURITY.md | ||
WATCHLISTS |
Dart
An approachable, portable, and productive language for high-quality apps on any platform
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).
License & patents
Dart is free and open source.
See LICENSE and PATENT_GRANT.
Using Dart
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).
Building Dart
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 on our wiki.
Contributing to Dart
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.