Aske Simon Christensen
51c4e03928
Changes the representation of closures to include a vtable with entry points for the various ways in which the function can be called. For each combination of type parameter count and positional parameter count, the names of named parameters occurring together with that combination are partitioned into clusters such that any combination of names that occurs together is contained within a single cluster. Each combination of type parameter count and positional parameter count gets a vtable layout for signatures without named parameters, plus one for each cluster of parameter names belonging to the combination. Each vtable layout will have an entry for each number of positional arguments from 0 up to the maximum number for the signature, followed by an entry for each (non-empty) combination of argument names from its cluster that occurs in a function call in the program. This layout scheme is consistent with function subtyping in the sense that if signature B is a subtype of signature A, then the Wasm struct for the vtable layout corresponding to B is a subtype of the Wasm struct for the vtable layout corresponding to A, i.e. the fields in the layout for A is a prefix of the fields in the layout for B. Change-Id: I36569be5251cc0cca4373b08c48d37c214478c3c Cq-Include-Trybots: luci.dart.try:dart2wasm-linux-x64-d8-try Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256822 Commit-Queue: Aske Simon Christensen <askesc@google.com> Reviewed-by: Joshua Litt <joshualitt@google.com>
Package validation
The packages in pkg/ are automatically validated on the LUCI CI bots. The
validation is largely done by the tools/package_deps package; it can be tested
locally via:
dart tools/package_deps/bin/package_deps.dart
Packages which are published
There are several packages developed in pkg/ which are published to pub.
Validation of these packages is particularly important because the pub tools are
not used for these packages during development; we get our dependency versions
from the DEPS file. Its very easy for the dependencies specified in a package's
pubspec file to get out of date wrt the packages and versions actually used.
In order to better ensure we're publishing correct packages, we validate some properties of the pubspec files on our CI system. These validations include:
- that the dependencies listed in the pubspec are used in the package
- that all the packages used by the source are listed in the pubspec
- that we don't use relative path deps to pkg/ or third_party/ packages
Packages which are not published
For packages in pkg/ which we do not intend to be published, we put the following comment in the pubspec.yaml file:
# This package is not intended for consumption on pub.dev. DO NOT publish.
publish_to: none
These pubspecs are still validated by the package validation tool. The contents are more informational as the pubspecs for these packages are not consumed by the pub tool or ecosystem.
We validate:
- that the dependencies listed in the pubspec are used in the package
- that all the packages used by the source are listed in the pubspec
- that a reference to a pkg/ package is done via a relative path dependency