Our maps are string-based and assume there's only one one @Native
class with a given name. This isn't true for these four classes,
where there are two types with the same name for each one.
This then results in us dropping the definition of one of the
two types.
Since one of the two types is essentially unused, we should choose
to drop that one instead for now. Long-term, we should deprecate
the unused types or change our conformance handling to handle
multiple types with the same name. We could also choose to unify
both definitions, but this may lead to either false positives or
renames of members being dropped.
This allows us to catch uses of the types that are actually used.
Change-Id: I9386cad5b014bee60cd72d21cdf0546640138704
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/341331
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Srujan Gaddam <srujzs@google.com>
The specification grammar has a rule for `initializerExpression` that
derives only `cascade` and `conditionalExpression`, whereas the
implementations allow throw expressions and assignments as well.
This CL broadens the grammar rule for `initializerExpression` such
that it derives the missing terms as well.
Change-Id: Iba3bb11623e07ac81cf9763228ae3e1b7b5204e3
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/340620
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This CL changes the specification grammar Dart.g such that it allows
using `p.Function` to denote the built-in type `Function`. This is
necessary in the case where 'dart:core' has been imported with an
import prefix `p` (and it hasn't been imported without a prefix at the
same time). The corresponding spec update is in
https://github.com/dart-lang/language/pull/3492.
Change-Id: Iaaba1c3bc8f5d3a8700c8e62ec3a1af92334840b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/339561
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
This language feature allows the user to declare a static type using
`extension type` syntax, for example:
extension type IdNumber(int i) {
operator <(IdNumber other) => i < other.i;
bool isValid(Some parameters) => ...;
}
This behaves similarly to a "wrapper" class:
class IdNumber {
final int i;
IdNumber(this.i);
operator <(IdNumber other) => i < other.i;
bool isValid(Some parameters) => ...;
}
However, at runtime, no wrapper objects are created; instead, an
instance of the extension type is represented directly by its
"representation type" (`int` in the above example), and methods like
`isValid` are resolved statically. This gives developers an
abstraction mechanism with the advantage of zero runtime performance
cost, since no extra heap space is required, and no extra instructions
are needed to convert between an extension type and its underlying
representation.
The disadvantage of using extension types as an abstraction mechanism
is that since no wrapper objects are created at runtime, the
abstraction can be bypassed using `dynamic`, runtime casts, or by
"laundering" the object through contravariant generic methods like
`List.add` (which are runtime checked in Dart). For example:
main() {
var id = IdNumber(1);
var list1 = <int>[];
List<Object> list2 = list1;
list2.add(id); // OK at compile time because `IdNumber` is a
// subtype of `Object`. OK at runtime because
// at runtime, `IdNumber` and `int` are
// indistinguishable.
int i = list1[0];
print(i);
}
Extension types are expected to be particularly useful for
low-overhead decoding of external data formats (such as JSON), and for
inter-operation with other languages (such as Javascript).
For additional information see the feature specification:
https://github.com/dart-lang/language/blob/main/accepted/future-releases/extension-types/feature-specification.md
Change-Id: I900a3a25dcfc38bfa9c9f9b5b9fa20f362883653
Tested: Standard trybots
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/335062
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Leaf Petersen <leafp@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
vm.
This identifies all calls to static methods annotated with
`@ResourceIdentifier`, collects the constant arguments passed to the
method, and writes the results into a file.
The purpose of this feature is to be able to pass the recorded
information to packages in a post-compilation step, allowing them to
remove or modify assets based on the actual usage in the code prior to
bundling in the final application.
Tested: pkg/vm/test/transformations/resource_identifier_test.dart
Change-Id: I58cb313b66ee23c1d154dcc242547723a1ced359
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/329961
Commit-Queue: Moritz Sümmermann <mosum@google.com>
Reviewed-by: Nate Bosch <nbosch@google.com>
Switch the Windows ARM64 builds to use MSVC. Clang disagrees with itself about handling of small structs in variadic functions, allowing splitting between the last argument register and the stack as the callee but not as the caller.
TEST=ci
Cq-Include-Trybots: luci.dart.try:vm-ffi-android-debug-arm-try,vm-ffi-android-debug-arm64c-try,vm-ffi-android-release-arm-try,vm-ffi-android-release-arm64c-try,vm-ffi-qemu-linux-release-arm-try,vm-linux-release-arm64-try,vm-mac-debug-arm64-try,vm-mac-release-arm64-try,vm-win-debug-arm64-try,vm-win-release-arm64-try,vm-ffi-qemu-linux-release-riscv64-try,vm-linux-debug-ia32-try,vm-linux-release-ia32-try,vm-win-release-ia32-try,vm-linux-debug-x64-try,vm-linux-release-x64-try,vm-mac-debug-x64-try,vm-mac-release-x64-try,vm-win-debug-x64-try,vm-win-release-x64-try
Bug: https://github.com/dart-lang/sdk/issues/52644
Bug: https://github.com/dart-lang/sdk/issues/53829
Change-Id: I2fd6c40620a885479f11bb8528ca1e9df3948a2f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/331209
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
**This change cannot easily be reverted**: After reverting this change,
dart-ci-internal-release-bucket-breakglass must be broken by a member of
Dart EngProd and gs://dart-archive/channels/main/raw/latest must be
purged as well as gs://dartlang-api-docs/channels/main/latest.txt. This
operation would risk our release security and it is strongly preferred
if any problems can be fixed forward instead.
This change will upload the main channel builds to the main directory in
the dart-archive bucket instead of the be directory. The existing builds
remain where they are and the last version on the be channel remains
permanently frozen.
The downstream uses already have forward compatibility for the new
channel name. The Dart recipes respect the input channel name and output
to the release location by that name. The api.dart.dev service will
notice when the main channel pops into existence and switch
api.dart.dev/be to become api.dart.dev/main. The setup-dart github
action will likewise notice when the main channel starts existing.
The main channel is not an officially supported product since the builds
are not signed and tested and we don't advertise the existence of these
builds to our users. Ideally nobody would be broken by this change since
they shouldn't be using the main channel builds, but if they are, they
will have to rename the channel in their download links.
This change ensures that all the release branches and release channels
have the same matching names, which simplifies our infrastructure and
makes our releases easier to understand.
Fixes: b/270022416
Change-Id: Ib47ae7d2ded5fe0d405b3f19c34981c38082a090
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/327940
Commit-Queue: Jonas Termansen <sortie@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
stringref target won't be used any time soon (probably ever). To help
with build times and avoid keeping it updated remove it for now.
Change-Id: I0df33b7ab2e19bae5090e8ea32ea6a3dc3751652
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/334881
Reviewed-by: Aske Simon Christensen <askesc@google.com>
Commit-Queue: Ömer Ağacan <omersa@google.com>
This can be controlled via codesigning_identity GN arg.
For example, setting codesigning_identity="-"
would produce ad-hoc signed binaries.
This CL also includes changes in vm/cc tests which are needed
for tests to be green when running with hardened runtime.
Issue https://github.com/dart-lang/sdk/issues/53928
Tested: enabled ad-hoc signing and tested on bots.
Cq-Include-Trybots: luci.dart.try:vm-mac-debug-arm64-try,vm-mac-release-arm64-try,vm-mac-release-x64-try,vm-mac-debug-x64-try
Change-Id: I3c3a6265c62b2904e43a326b7d8223bcfd393577
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333401
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
The Dart2JS team has agreed that this mode of compilation is no longer worth investing in at this time and its existence adds some overhead to other feature work so it is worth fully removing. In the future we may revisit this mode of compilation. Below is some more context for any future exploration in this space.
What didn't work with modular analysis:
- current modular analysis was computing impacts, which were dense (50% of the size of kernel)
- using it moved work to a modular phase, and cut Phase1 in half however end-to-end time was not better
- data overhead was very high
- it made it much harder to maintain invariants throughout the pipeline: the data is tightly coupled with the kernel AST, making it hard to make late modifications to the AST.
How to potentially make it better:
- make the data much more sparse
- make the data more independent from the kernel AST so that transformations are not breaking
- reduce the critical path in a more substantial way.
Note: We retain and ignore the commandline flags used for modular analysis in order to avoid breaking build pipelines that were passing them. We may remove these at a later date.
Change-Id: If574ce2358280ab5fedd89c62665328601e72e22
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/333360
Reviewed-by: Mayank Patke <fishythefish@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Build one package with three elf_test_runner components: one for each of the binaries that the test harness invokes on the target. (Though currently only tests that use "dart" are setup.)
Create includable CML shards for the capabilites required by the AOT and JIT VMs.
Fold test_runner's fuchsia_cfv2.dart back into fuchsia.dart.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/38752
Change-Id: I7bd8d43d184cbcb11903c7aed77ce31fb30cb894
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/332451
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Zijie He <zijiehe@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Also renames the test configurations for x64 to include the architecture.
Cq-Include-Trybots: luci.dart.try:pkg-linux-debug-try,pkg-linux-release-try,pkg-mac-release-arm64-try,pkg-mac-release-try,pkg-win-release-try
Change-Id: I76e259a059e9fe16f4799d65f2bb5380a9c6fb94
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/330028
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Alexander Thomas <athom@google.com>
Jonas Termansen