Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

refactor: centralize&improve infrastructure for building test contracts #4160

Merged
merged 3 commits into from
Mar 26, 2021

Conversation

matklad
Copy link
Contributor

@matklad matklad commented Mar 24, 2021

  • Move test contracts to the dedicated runtime/near-test-contracts folder
  • Do not commit .wasm files and instead re-build them on the fly
    when necessary
  • Use build.rs rather than build.sh for compilation
  • Replace lazy_static_include calls with centralized functions

@matklad
Copy link
Contributor Author

matklad commented Mar 24, 2021

Backstory here: I've noticed that our sum_n method doesn't actually sum the n numbers, as LLVM can compute sums of polynomial terms in closed form. I wanted to fix that (as we do use that method for benchmarking), but realized that I would need to build wasm locally and commit it.

@matklad matklad force-pushed the near-test-contracts branch 4 times, most recently from 61400d1 to 584b594 Compare March 24, 2021 11:33
@matklad
Copy link
Contributor Author

matklad commented Mar 24, 2021

One thing I am not sure here is whether our python tests are guaranteed to run only after cargo build. Some of them read .wasm directly from the res folder, and, to populate res, building rust code is required.

Comment on lines 26 to 32
pub fn default_code_hash() -> CryptoHash {
let mut path = PathBuf::from(env!("CARGO_MANIFEST_DIR"));
path.push("../../runtime/near-vm-runner/tests/res/test_contract_rs.wasm");
let genesis_wasm = fs::read(path).unwrap();
hash(&genesis_wasm)
hash(&near_test_contracts::rs_contract())
}

lazy_static::lazy_static! {
static ref DEFAULT_TEST_CONTRACT_HASH: CryptoHash = hash(&DEFAULT_TEST_CONTRACT);
}

lazy_static_include::lazy_static_include_bytes! {
DEFAULT_TEST_CONTRACT => "../../runtime/near-vm-runner/tests/res/test_contract_rs.wasm"
static ref DEFAULT_TEST_CONTRACT_HASH: CryptoHash = hash(near_test_contracts::rs_contract());
}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems to be some pre-existing duplication: default_code_hash and DEFAULT_TEST_CONTRACT compute the same thing. Left as is, as out of scope for the PR.

Copy link
Contributor

@chefsale chefsale left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Seems like tests are failing, lets fix that first. 😄

@matklad matklad force-pushed the near-test-contracts branch 2 times, most recently from 4d414c0 to 023a71d Compare March 24, 2021 12:50
@@ -0,0 +1,10 @@
[package]
name = "near-test-contracts"
version = "0.0.0"
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does 0.0.0 make sense?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does -- we are not going to publish this crate, so it doesn't have a meaningful semver. So putting a default 0.1.0 would be (a minor and insignificant) lie. 0.0.0 and publish = false explicitly say that we don't care about semver in this case.

fn test_contract() -> ContractCode {
ContractCode::new(TEST_CONTRACT.to_vec(), None)
let code = if cfg!(feature = "protocol_feature_alt_bn128") {
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems off to me. It should be based on whether nightly_protocol is enabled.

Copy link
Contributor Author

@matklad matklad Mar 24, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably! I've tried to keep pre-existing semantics in this PR, I can change this and that in a follow up.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Took a look here, I am not sure how to fix it. This crate doesn't have nightly_protocol feature:

[features]
# all vms enabled for tests, but only one default vm, specified by runtime crate
default = ["wasmer0_vm", "wasmtime_vm", "wasmer1_vm"]
wasmer0_vm = [ "wasmer-runtime" ]
wasmtime_vm = [ "wasmtime", "anyhow"]
wasmer1_vm = [ "wasmer", "wasmer-types", "wasmer-compiler-singlepass",  "wasmer-compiler-cranelift", "wasmer-engine-native", ]
lightbeam = ["wasmtime/lightbeam"]
no_cpu_compatibility_checks = []
protocol_feature_evm = ["near-primitives/protocol_feature_evm", "near-evm-runner/protocol_feature_evm"]

no_cache = []

protocol_feature_alt_bn128 = [
    "near-vm-logic/protocol_feature_alt_bn128",
    "near-primitives/protocol_feature_alt_bn128",
    "near-vm-errors/protocol_feature_alt_bn128"
]

At this point, I don't know the purpose of nightly_protocol and nightly_protocol_features cargo features and why they are set up that way, so I can't immediately fix that. Learning more about our feature setup is on my todo list, so I might come back to this later.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@matklad nightly_protocol is supposed to be a marker feature near/NEPs#126 (comment)

@matklad matklad force-pushed the near-test-contracts branch 7 times, most recently from 247b8a0 to 6420c4a Compare March 24, 2021 15:58
@matklad
Copy link
Contributor Author

matklad commented Mar 24, 2021

Got this past CI, including the "One thing I am not sure here is whether our python tests are guaranteed to run only after cargo build" bit.

should be ready for review.

* Move test contracts to the dedicated `runtime/near-test-contracts` folder
* Do not commit `.wasm` files and instead re-build them on the fly
  when necessary
* Use build.rs rather than build.sh for compilation
* Replace lazy_static_include calls with centralized functions
format!("./res/{}.wasm", output),
)?;
println!("cargo:rerun-if-changed=./{}/src/lib.rs", dir);
println!("cargo:rerun-if-changed=./{}/Cargo.toml", dir);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What are these println?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They tell cargo when it needs to rebuild the test contracts, These are documented in https://doc.rust-lang.org/cargo/reference/build-scripts.html#outputs-of-the-build-script

In theory, we maybe can just always run cargo build here, as that should be a no-op, but it wasn't hard to save an extra process invocation here.

@near-bulldozer near-bulldozer bot merged commit a767e46 into near:master Mar 26, 2021
@matklad matklad deleted the near-test-contracts branch April 13, 2021 18:16
matklad added a commit to matklad/nearcore that referenced this pull request Apr 13, 2021
They were extracted out of near-vm-runner in
near#4160
but I forgot to update codeowners.
near-bulldozer bot pushed a commit that referenced this pull request Apr 14, 2021
* add myself as a codeowner 
* fixup #4160 to re-install codeowners for the new crate.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants