Allow a kernel snapshot to be compiled

[nex3]

Currently, if I try to run dart compile with a kernel snapshot as an input, it crashes with a bunch of errors like the following:

test.dart.snapshot:1:1: Error: Unable to decode bytes as UTF-8.
����E2102c6ce7a��������!A��
^

Since the normal dart runner itself can take a kernel snapshot, I'd expect dart compile to be able to as well. This would be useful for distributing installers that run dart compile exe on the local user's workstation on a single snapshot file, as a way of avoiding code signing issues and working around the lack of cross-compilation (#28617).

[a-siva]

removing area-vm as this support can be provided purely from the dart-cli tool.

[bsutton]

I would also like to see this feature supported.

I'm trying to implement incremental compilation in the dcli package for users that need an exe to test with Sudo or remote deployments. This feature would speed up development iterations for users of dcli.

[bkonyi]

@nex3 I don't think this will work for your use case as there's no stable ABI between the VM and kernel, so the user invoking dart compile will need to have exactly the same SDK version that was used to generate the kernel file. There's no plan to create a stable ABI and providing a way to compile from kernel probably doesn't add much value if the kernel already needs to be generated by the current SDK.

The right way to solve this distribution issue is for us to support cross-compilation, but I have no update on the progress on that front.

@bsutton we don't currently have support for AOT compilation from incremental kernel files, and such support would likely lead to little to no performance improvements as the global analysis done during the initial compilation would need to be completely invalidated to take into account changes to the program structure.

I'm going to close this issue as I don't think this feature is worth adding at this point as it will only work in very limited scenarios.

[nex3]

It's pretty easy to ensure that users get the same version of the SDK that was used to compile a kernel file. We already ensure that SDK versions are consistent in order to guarantee that the code runs against the same version of Dart it was tested against (different Dart versions have enough breaking changes between them that this is an unfortunate necessity).

Other than this one case, the dart executable provides the invariant that anything that can be run can also be compiled. Even if you don't think the use-case is particularly valuable, maintaining invariants like that is very helpful to making tooling easy for users to reason about and work with.