search

anza-xyz / move

Move compiler targeting llvm supported backends
https://discord.gg/wFgfjG9J
Apache License 2.0
108 stars 34 forks source link

Add new backend to Move compiler targeting Solana VM #304

Closed dmakarov closed 1 year ago

dmakarov commented 1 year ago

These changes implement Move to Solana VM compiler as a new backend of the the existing Move compiler with move-cli controlling the compilation and invoking the solana backend on modules of a Move package via proper function calls.

The move-mv-llvm-compiler cli remains unchanged. The compiler itself is moved to languages/solana subdir.

dmakarov commented 1 year ago

@jcivlin I reworked the PR, leaving the move-mv-llvm-compiler standalone application intact, with all the options and package handling that you added. All the reimplementations of move-package functionality that you added also remains in the move-mv-llvm-compiler. All your tests are there as well. I added one new test case to test building a package using move build --arch solana command and running the generated executable module.

jcivlin commented 1 year ago

If this PR is not merged

  1. move-mv-llvm-compiler will keep dependencies on crates move-cli, move-packages, and others that you added when you implemented -p and —stdlib options;
  2. if more bugs are found in crates move-cli, move-packages, and others, dependencies on which you added, you will fix the bugs by reimplementing the corresponding functionality from those crates inside the move-mv-llvm-compiler, instead of fixing them in the crates that have the bugs;
  3. in your terms the item 2 above is not a subscription to online patching because instead of patching bugs in-place the functionality is reimplemented inside move-mv-llvm-compiler.

Also from your other comment I understand that merging this PR opens a Pandora’s box but adding crates move-package, move-cli as dependencies to move-mv-llvm-compiler crate was not opening Pandora’s box.

Is my understanding correct?

Correct. By "opening Pandora's box" I mean the existing deviation between Diem and Aptos (and maybe Sui). So we will be different no matter what and adding new flags is ok.

jcivlin commented 1 year ago

@jcivlin I reworked the PR, leaving the move-mv-llvm-compiler standalone application intact, with all the options and package handling that you added. All the reimplementations of move-package functionality that you added also remains in the move-mv-llvm-compiler. All your tests are there as well. I added one new test case to test building a package using move build --arch solana command and running the generated executable module.

This is good. This part is easy (after two takes) to integrate with Aptos with minimal changes in Aptos tree.