This reverts commit 38ef28a058.
Reason for revert: Breaks build on debug mode 32-bit arches,
release mode simarm_x64
Issue: https://github.com/dart-lang/sdk/issues/60307
Original change's description:
> [vm, gen_snapshot] Add app-aot-macho-dylib option for AOT snapshots.
>
> This is the initial framework for creating snapshots as Mach-O dynamic
> libraries. Note that this framework is not 100% feature complete
> compared to generating Mach-O snapshots via assembly. In particular,
> the directly-compiled Mach-O dylib does not yet contain compact
> unwinding information.
>
> Other changes:
>
> * Adds UuidCommand to the native_stack_traces package's Mach-O reader,
> which now appropriately returns the UUID as the build ID for Mach-O
> shared objects.
>
> * Adds Utils::Basename(path) for portably retrieving the basename
> from a path. (Returns nullptr for all arguments where it is not
> currently implemented on Fuchsia or Windows.)
>
> * Adjusts vm/timeline.h to avoid pulling in <mach_o/loader.h> on MacOS,
> as that interferes with uses of the namespaced Mach-O definitions
> in platform/mach_o.h.
>
> * Only attempt to dlopen() a snapshot if ELF is the native format
> for the host platform or the snapshot is not an ELF shared object.
> If dlopen() is used, report the error message if it fails rather
> than attempting to manually load the snapshot as an ELF shared object.
>
> * Fix the magic number stored in DylibAppSnapshot for loaded non-ELF
> dynamic libraries.
>
> * Remove the detection of reverse-endian Mach-O magic numbers in
> DartUtils::SniffForMagicNumber(), since all our Mach-O related code
> assumes host-endian Mach-O files and so there's no point other than
> to give a slightly better error message when failing.
>
> TEST=vm/dart/exported_symbols_test
> vm/dart/unobfuscated_static_symbols_test
> vm/dart/use_dwarf_stack_traces_flag_test
> vm/cc/CanDetectMachOFiles
>
> Issue: https://github.com/dart-lang/sdk/issues/60307
> Change-Id: Idf5b49d6c6d035ab033509613212b95520d65965
> Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-mac-release-arm64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-dwarf-linux-product-x64-try,vm-linux-debug-x64-try,vm-mac-debug-arm64-try,vm-fuchsia-release-x64-try,vm-fuchsia-release-arm64-try
> Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415020
> Reviewed-by: Slava Egorov <vegorov@google.com>
> Commit-Queue: Tess Strickland <sstrickl@google.com>
Issue: https://github.com/dart-lang/sdk/issues/60307
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-mac-release-arm64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-dwarf-linux-product-x64-try,vm-linux-debug-x64-try,vm-mac-debug-arm64-try,vm-fuchsia-release-x64-try,vm-fuchsia-release-arm64-try
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Change-Id: Iff2ab4c84a513a184784129f456bd357ae8e3a67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/431220
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Slava Egorov <vegorov@google.com>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Auto-Submit: Tess Strickland <sstrickl@google.com>
Currently, the configuration code only has a boolean option, 'use-elf'
for specifying the output format for gen_snapshot. If false, then the
output format is assumed to be assembly.
Add a new GenSnapshotFormat enum and replace the old 'use-elf' option
with a new 'gen-snapshot-format' option. The new enum has two getters:
* snapshotType returns the appropriate string to pass to gen_snapshot
via the '--snapshot-type' option.
* fileOption returns the name of the option used to specify the
output path for the given format.
In addition, make it so the Configuration only has a non-null
genSnapshotFormat field if the compiler is Compiler.dartkp to avoid
spurious differences in Configurations that are created with different
GenSnapshotFormat values when the configurations in question don't
actually call gen_snapshot.
TEST=pkg/smith/test/configuration_test.dart (and the CI in general)
Change-Id: I7f17dc8d3a1bb6d4bf57750bc5ef4a16b8a78c11
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429980
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
This is the initial framework for creating snapshots as Mach-O dynamic
libraries. Note that this framework is not 100% feature complete
compared to generating Mach-O snapshots via assembly. In particular,
the directly-compiled Mach-O dylib does not yet contain compact
unwinding information.
Other changes:
* Adds UuidCommand to the native_stack_traces package's Mach-O reader,
which now appropriately returns the UUID as the build ID for Mach-O
shared objects.
* Adds Utils::Basename(path) for portably retrieving the basename
from a path. (Returns nullptr for all arguments where it is not
currently implemented on Fuchsia or Windows.)
* Adjusts vm/timeline.h to avoid pulling in <mach_o/loader.h> on MacOS,
as that interferes with uses of the namespaced Mach-O definitions
in platform/mach_o.h.
* Only attempt to dlopen() a snapshot if ELF is the native format
for the host platform or the snapshot is not an ELF shared object.
If dlopen() is used, report the error message if it fails rather
than attempting to manually load the snapshot as an ELF shared object.
* Fix the magic number stored in DylibAppSnapshot for loaded non-ELF
dynamic libraries.
* Remove the detection of reverse-endian Mach-O magic numbers in
DartUtils::SniffForMagicNumber(), since all our Mach-O related code
assumes host-endian Mach-O files and so there's no point other than
to give a slightly better error message when failing.
TEST=vm/dart/exported_symbols_test
vm/dart/unobfuscated_static_symbols_test
vm/dart/use_dwarf_stack_traces_flag_test
vm/cc/CanDetectMachOFiles
Issue: https://github.com/dart-lang/sdk/issues/60307
Change-Id: Idf5b49d6c6d035ab033509613212b95520d65965
Cq-Include-Trybots: luci.dart.try:vm-aot-linux-debug-x64-try,vm-mac-release-arm64-try,vm-aot-mac-release-arm64-try,vm-aot-mac-release-x64-try,vm-aot-dwarf-linux-product-x64-try,vm-linux-debug-x64-try,vm-mac-debug-arm64-try,vm-fuchsia-release-x64-try,vm-fuchsia-release-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/415020
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Tess Strickland <sstrickl@google.com>
Default types are used in the exhaustiveness computation but were not
computed for local functions, leading to a crash during constant
evaluation. This adds computation of default types to
FunctionDeclaration and FunctionExpression.
Closes#54388Closes#60264
Change-Id: I95eb2ae5b42e4fb5ab77088c915fe6088a1d4060
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/427702
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
This adds support for constant evaluation of null aware access of length
on null. Null aware access of length on String was already supported in
both analyzer and CFE, and the spec has been updated to support it.
Closes#60509
Change-Id: Ie7e26d3e969bc82f5c65147f243350fbf4c68e67
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/429921
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
These packages can be specified with the `non-hot-reloadable-package` flag and will be compiled without their members being properly hot reloadable. In exchange, we can perform additional optimizations (such as avoiding levels of indirection/checks in anticipation of their being updated).
This additionally overhauls our memory compiler to use the incremental compiler for proper state-passing hot reload testing + adds tests for this functionality.
Change-Id: Ief65896410f32655f064bd15728703629faa4051
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/428343
Reviewed-by: Nate Biggs <natebiggs@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Mark Zhou <markzipan@google.com>
These mixin constructors are now marked callable by the dynamic interface annotator: https://dart-review.googlesource.com/c/sdk/+/430002
However, they are not directly invokeable and trying to compile the constructor entrypoints causes dart2wasm to crash. So we explicitly skip them when considering dynamic callable constructors.
Note: This is blocking internal rolls as code patterns like this show up in our internal codebase.
Change-Id: I76383aec07bc53a0dbd1581c0577cba370d956f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430801
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
Auto-Submit: Nate Biggs <natebiggs@google.com>
Attempting to use the native definition when available causes problems
when cross-compiling, and the original attempts to avoid this broke in
subtle ways. Instead, just make a non-native definition that mimics
the native definition and use that with reinterpret_casts when sending
uses of the non-native definition to Windows API calls that expect
a value of the native definition.
TEST=windows ci
Fixes: https://github.com/dart-lang/sdk/issues/60771
Change-Id: I347fcaf8cccd809a3d8e6f041cc7e360b0b8226e
Cq-Include-Trybots: luci.dart.try:vm-aot-win-release-arm64-try,vm-aot-win-release-x64-try,vm-win-release-arm64-try,vm-win-release-x64-try,vm-aot-win-debug-arm64-try,vm-aot-win-debug-x64-try,pkg-win-release-try,pkg-win-release-arm64-try,dart-sdk-win-try,dart-sdk-win-arm64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430400
Reviewed-by: Slava Egorov <vegorov@google.com>
For a few months the "original" flutter gallery has had compile errors
and the weekly bot has been a lot slower (and doesn't really test the
default "advanced invalidation").
This updates the compile target to the one in
flutter/dev/integration_tests/new_gallery which doesn't have compile
time errors.
Change-Id: I59aa701700bc6b3530d73d9c0474dbff525288c5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430700
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This CL includes changes to BenchMaker and test type parser that
include recent developments in the DartType system, such as extension
types and record types, outstanding existing features, such as
typedefs, and recent changes in the CFE type model, such as structural
parameters.
Change-Id: I16ca13273e83de7942abad67b8a2b67146fb24bf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430661
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This combines the creation SourcePropertyBuilder for fields, getters,
setters, enum elements and primary constructor fields through the same
method.
This prepares for combining getter/setter and final field/setter
pairs in the same SourcePropertyBuilder.
Change-Id: I664ccded46c79235281cbd0799f9567bfb451eb2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430440
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
We add the `dart.tool.dart2wasm.minify` environment define (analogous to
how dart2js exposes `dart.tool.dart2js.minify`).
We make `package:expect/variations.dart` then expose to tests what
guarantees they can assume, namely
* `readableTypeStrings`
* `preciseErrorsWithDetails`
Change-Id: I43da09ed924ca9137721f4d70b7a494e01bf36e4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430680
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
Make the `HInstruction.sideEffects` field final. The instruction owns
the mutable SideEffects objects so it would be dangerous to make the
field reference a shared SideEffects object.
Update the side effects of an interface call when the target becomes
known. We were essentially missing any benefit of inferred
side-effects for instance members.
Change-Id: I46da1d87e166864cd7fa4cee01f209bcc19986af
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430546
Commit-Queue: Stephen Adams <sra@google.com>
Reviewed-by: Nate Biggs <natebiggs@google.com>
- For direct calls in selector branch, ensure 'if' branches have correct inputs.
- For overrideable selectors, the receiver type cannot be known in the main module so use 'top' type. Technically we could do better if selectors tracked interfaces they targeted. Then we could take the LUB of all those classes. But this would be a significant refactor for a small benefit.
- Type checks on classes defined in the main module should use the class ID ranges from the main module rather than those from the dynamic submodule. This only applies to non-dynamic module extendable types (otherwise we'd use the RTT checks). So we know the class can only exist in one of the range sets, not both.
I discovered (1) from running Flutter which led me to create this test which uncovered (2) and (3).
Change-Id: I80f39835f66aa7cf0cff527341e3f4a948a7a0cb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430360
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This CL contains no functional differences; it just reorganizes the code.
I expect to be adding data to the collected report, and I decided that
it would be better to break the massive method up before doing so in
order to improve overall readability.
I also wondered whether we might want to structure the data in a similar
way. For example, the top-level map could have entries corresponding to
each of these methods, each of which has a value that is a map
containing the data collected by that method. I don't know whether this
would make the output easier to read or whether the current form is
depended on anywhere, but it's something to consider for the future.
Change-Id: Id0ef3c2f64b00ea58069c496e7c485c7b3f163c9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/430560
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Tess Strickland