| commit | 6a9216a46fcf82fdffe3568fe80ee32be583dfcf | [log] [tgz] |
|---|---|---|
| author | Paul Berry <paulberry@google.com> | Tue Dec 19 00:08:19 2023 +0000 |
| committer | Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> | Tue Dec 19 00:08:19 2023 +0000 |
| tree | 77869b218530a3a7a6e43f3f8c81a8c7ebd4b50f | |
| parent | d646c92abe60453bbcd755572db7a51b011baad8 [diff] |
Remove Requirements=nnbd-weak from superinterfaces_out_of_order_error_test.dart. The annotation `Requirements=nnbd-weak` controls prevents a test from being run on a platform that doesn't have weak mode runtime semantics (e.g. a program running with sound null safety). In a previous CL (https://dart-review.googlesource.com/c/sdk/+/341020), I removed several tests from `tests/language` that contained legacy code, in order to unblock removal of legacy support from the analyzer; those tests all contained this annotation. However, after discussion with Siggi, we've decided that it would be better to keep those tests around for a while longer, because they exercise important runtime behaviors of unsound null safety mode on the web and VM platforms, and not all google3 code has been migrated off of unsound null safety mode yet. So, I intend to take a different approach to unblocking removal of legacy support from the analyzer: stop running tests with the annotation `Requirements=nnbd-weak` through the analyzer. This will allow the tests removed in https://dart-review.googlesource.com/c/sdk/+/341020 to be restored, but it will have a side effect of causing a small number of additional analyzer tests to be skipped. All those tests are benign to skip on the analyzer (because they are purely concerned with runtime semantics) except for one: `superinterfaces_out_of_order_error_test.dart`. This test doesn't have any runtime semantics at all; it merely checks that the analyzer and CFE produce the correct errors for certain compile-time type checks that have nothing to do with weak mode runtime semantics. So, to prevent a gap in test coverage when the analyzer begins skipping tests annotated with `Requirements=nnbd-weak`, we need to remove this annotation from `superinterfaces_out_of_order_error_test.dart`. Change-Id: I7932a0200be750116c41a303b48aaef50bc952ec Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341980 Reviewed-by: Sigmund Cherem <sigmund@google.com> Commit-Queue: Paul Berry <paulberry@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 on our wiki.
The easiest way to contribute to Dart is to file issues.
You can also contribute patches, as described in Contributing.