You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

194 lines
6.6 KiB

Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Add solidity groth16, kzg10 and final decider verifiers in a dedicated workspace (#70) * change: Refactor structure into workspace * chore: Add empty readme * change: Transform repo into workspace * add: Create folding-verifier-solidity crate * add: Include askama.toml for `sol` extension escaper * add: Jordi's old Groth16 verifier .sol template and adapt it * tmp: create simple template struct to test * Update FoldingSchemes trait, fit Nova+CycleFold - update lib.rs's `FoldingScheme` trait interface - fit Nova+CycleFold into the `FoldingScheme` trait - refactor `src/nova/*` * chore: add serialization assets for testing Now we include an `assets` folder with a serialized proof & vk for tests * Add `examples` dir, with Nova's `FoldingScheme` example * polishing * expose poseidon_test_config outside tests * change: Refactor structure into workspace * chore: Add empty readme * change: Transform repo into workspace * add: Create folding-verifier-solidity crate * add: Include askama.toml for `sol` extension escaper * add: Jordi's old Groth16 verifier .sol template and adapt it * tmp: create simple template struct to test * feat: templating kzg working * chore: add emv and revm * feat: start evm file * chore: add ark-poly-commit * chore: move `commitment` to `folding-schemes` * chore: update `.gitignore` to ignore generated contracts * chore: update template with bn254 lib on it (avoids import), update for loop to account for whitespaces * refactor: update template with no lib * feat: add evm deploy code, compile and create kzg verifier * chore: update `Cargo.toml` to have `folding-schemes` available with verifiers * feat: start kzg prove and verify with sol * chore: compute crs from kzg prover * feat: evm kzg verification passing * tmp * change: Swap order of G2 coordinates within the template * Update way to serialize proof with correct order * chore: update `Cargo.toml` * chore: add revm * chore: add `save_solidity` * refactor: verifiers in dedicated mod * refactor: have dedicated `utils` module * chore: expose modules * chore: update verifier for kzg * chore: rename templates * fix: look for binary using also name of contract * refactor: generate groth16 proof for sha256 pre-image, generate groth16 template with verifying key * chore: template renaming * fix: switch circuit for circuit that simply adds * feat: generates test data on the fly * feat: update to latest groth16 verifier * refactor: rename folder, update `.gitignore` * chore: update `Cargo.toml` * chore: update templates extension to indicate that they are templates * chore: rename templates, both files and structs * fix: template inheritance working * feat: template spdx and pragma statements * feat: decider verifier compiles, update test for kzg10 and groth16 templates * feat: parameterize which size of the crs should be stored on the contract * chore: add comment on how the groth16 and kzg10 proofs will be linked together * chore: cargo clippy run * chore: cargo clippy tests * chore: cargo fmt * refactor: remove unused lifetime parameter * chore: end merge * chore: move examples to `folding-schemes` workspace * get latest main changes * fix: temp fix clippy warnings, will remove lints once not used in tests only * fix: cargo clippy lint added on `code_size` * fix: update path to test circuit and add step for installing solc * chore: remove `save_solidity` steps * fix: the borrowed expression implements the required traits * chore: update `Cargo.toml` * chore: remove extra `[patch.crates-io]` * fix: update to patch at the workspace level and add comment explaining this * refactor: correct `staticcall` with valid input/output sizes and change return syntax for pairing * refactor: expose modules and remove `dead_code` calls * chore: update `README.md`, add additional comments on `kzg10` template and update `groth16` template comments * chore: be clearer on attributions on `kzg10` --------- Co-authored-by: CPerezz <c.perezbaro@gmail.com> Co-authored-by: arnaucube <root@arnaucube.com>
10 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
Enable WASM-compat and monitor it in the CI (#142) * fix: Use `target_pointer_size` conditional compilation There are some parts of the code where is needed to de/serialze `usize`s. These, have sizes that vary depending on the target achitecture the code is compiled for. Hence, this adapts the de/serialization to the specific pointer size for which the crate is being compiled to. * change: Support WASM-compatibility and polish Cargo.toml In order to support Wasm-compat and to simplify and improve `Cargo.toml` readability, the follwing changes have been made: - All the deps that can use `parallel` feature, do so. As `rayon` supports non-threaded targets with a fallback option. See: https://docs.rs/rayon-core/1.12.1/rayon_core/index.html#global-fallback-when-threading-is-unsupported - `ark-grumpking` has been brought to `0.5.0-alpha.0` as `0.4.0` appears to not be in `crates.io` anymore. See: https://crates.io/crates/ark-grumpkin/versions - By default, the crate uses `"ark-circom/default"` which selects the `wasmer/sys` feature such that it knows where wasmer is suposed to be run`. - Added a `wasm` feature which forces `ark-circom/wasm` to be used instead. Which internally selects the `wasmer/js` backend to be used such that in-browser execution is possible. - Added `getrandom` with `js` feature as dependency when `wasm32-unknown-unknown` target is selected such that compilation of the crate for testing or simply building is possible. Notice that with `wasi` and other wasm targets, this is not the case as they're automatically supported. For more info, please check: https://docs.rs/getrandom/latest/getrandom/#webassembly-support * feat: Support WASM-compatibility tests in CI Add support for both testing the build of `sonobe/folding-schemes` for WASM-targets and also, it's build as a dependency for a WASM-crate. This includes a build job for the three main supported rust-WASM targets and the same but for a thrid crate creted on-the-fly which uses `sonobe/folding-schemes` as a dependency. * chore: Add README docs about WASM-compat & feats * ci: don't run WASM-compat job if PR is draft * chore: depend on `arnaucube/circom-compat` fork. Since https://github.com/arnaucube/circom-compat/pull/2 was merged, we can already switch to it as we were depending before. * chore: minimal build/test instructions * fix: CI typos * fix: Update CI to use correct feature sets * fix: `ark-grumpkin` versioning issues As mentioned in https://github.com/privacy-scaling-explorations/sonobe/issues/146 there's a big issue that involves some dependencies of the crate. As a temporary fix, this forces the workspace to rely on a "non-existing" version of `ark-grumpkin` which is immediately patched at workspace-level for a custom version that @arnaucube owns with some cherry-picked commits. While this allows the CI to pass and crate to build, a better solution is needed. * fix: Clippy CI avoiding --all-targets * fix: use `wasm` feat only with folding-schemes
4 months ago
  1. name: CI Check
  2. on:
  3. merge_group:
  4. pull_request:
  5. push:
  6. branches:
  7. - main
  8. env:
  9. CARGO_TERM_COLOR: always
  10. # Disable incremental compilation.
  11. #
  12. # Incremental compilation is useful as part of an edit-build-test-edit cycle,
  13. # as it lets the compiler avoid recompiling code that hasn't changed. However,
  14. # on CI, we're not making small edits; we're almost always building the entire
  15. # project from scratch. Thus, incremental compilation on CI actually
  16. # introduces *additional* overhead to support making future builds
  17. # faster...but no future builds will ever occur in any given CI environment.
  18. #
  19. # See https://matklad.github.io/2021/09/04/fast-rust-builds.html#ci-workflow
  20. # for details.
  21. CARGO_INCREMENTAL: 0
  22. # Allow more retries for network requests in cargo (downloading crates) and
  23. # rustup (installing toolchains). This should help to reduce flaky CI failures
  24. # from transient network timeouts or other issues.
  25. CARGO_NET_RETRY: 10
  26. RUSTUP_MAX_RETRIES: 10
  27. # Don't emit giant backtraces in the CI logs.
  28. RUST_BACKTRACE: short
  29. # Jobs launched for a PR event cancel the ongoing one for the same workflow + PR,
  30. # Only retries (of the same run) for a Push event cancel the prior one.
  31. concurrency:
  32. group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  33. cancel-in-progress: true
  34. jobs:
  35. test:
  36. if: github.event.pull_request.draft == false
  37. name: Test
  38. runs-on: ubuntu-latest
  39. strategy:
  40. matrix:
  41. feature_set: [basic]
  42. include:
  43. - feature_set: basic
  44. features: --features default,light-test
  45. steps:
  46. - uses: actions/checkout@v2
  47. - uses: actions-rs/toolchain@v1
  48. - uses: noir-lang/noirup@v0.1.3
  49. with:
  50. toolchain: nightly
  51. - name: Download Circom
  52. run: |
  53. mkdir -p $HOME/bin
  54. curl -sSfL https://github.com/iden3/circom/releases/download/v2.1.6/circom-linux-amd64 -o $HOME/bin/circom
  55. chmod +x $HOME/bin/circom
  56. echo "$HOME/bin" >> $GITHUB_PATH
  57. - name: Download solc
  58. run: |
  59. curl -sSfL https://github.com/ethereum/solidity/releases/download/v0.8.4/solc-static-linux -o /usr/local/bin/solc
  60. chmod +x /usr/local/bin/solc
  61. - name: Execute compile.sh to generate .r1cs and .wasm from .circom
  62. run: ./frontends/src/circom/test_folder/compile.sh
  63. - name: Execute compile.sh to generate .json from noir
  64. run: ./frontends/src/noir/test_folder/compile.sh
  65. - name: Run tests
  66. uses: actions-rs/cargo@v1
  67. with:
  68. command: test
  69. args: --release --workspace --no-default-features ${{ matrix.features }}
  70. - name: Run Doc-tests
  71. uses: actions-rs/cargo@v1
  72. with:
  73. command: test
  74. args: --doc
  75. build:
  76. if: github.event.pull_request.draft == false
  77. name: Build target ${{ matrix.target }}
  78. runs-on: ubuntu-latest
  79. strategy:
  80. matrix:
  81. target:
  82. - wasm32-unknown-unknown
  83. - wasm32-wasi
  84. # Ignoring until clear usage is required
  85. # - wasm32-unknown-emscripten
  86. steps:
  87. - uses: actions/checkout@v3
  88. - uses: actions-rs/toolchain@v1
  89. with:
  90. override: false
  91. default: true
  92. - name: Add target
  93. run: rustup target add ${{ matrix.target }}
  94. - name: Wasm-compat frontends build
  95. uses: actions-rs/cargo@v1
  96. with:
  97. command: build
  98. args: -p frontends --no-default-features --target ${{ matrix.target }} --features "wasm, parallel"
  99. - name: Wasm-compat folding-schemes build
  100. uses: actions-rs/cargo@v1
  101. with:
  102. command: build
  103. args: -p folding-schemes --no-default-features --target ${{ matrix.target }} --features "default,light-test"
  104. - name: Run wasm-compat script
  105. run: |
  106. chmod +x .github/scripts/wasm-target-test-build.sh
  107. .github/scripts/wasm-target-test-build.sh
  108. shell: bash
  109. examples:
  110. if: github.event.pull_request.draft == false
  111. name: Run examples & examples tests
  112. runs-on: ubuntu-latest
  113. steps:
  114. - uses: actions/checkout@v2
  115. - uses: actions-rs/toolchain@v1
  116. - uses: noir-lang/noirup@v0.1.3
  117. with:
  118. toolchain: nightly
  119. - name: Download Circom
  120. run: |
  121. mkdir -p $HOME/bin
  122. curl -sSfL https://github.com/iden3/circom/releases/download/v2.1.6/circom-linux-amd64 -o $HOME/bin/circom
  123. chmod +x $HOME/bin/circom
  124. echo "$HOME/bin" >> $GITHUB_PATH
  125. - name: Download solc
  126. run: |
  127. curl -sSfL https://github.com/ethereum/solidity/releases/download/v0.8.4/solc-static-linux -o /usr/local/bin/solc
  128. chmod +x /usr/local/bin/solc
  129. - name: Execute compile.sh to generate .r1cs and .wasm from .circom
  130. run: ./frontends/src/circom/test_folder/compile.sh
  131. - name: Execute compile.sh to generate .json from noir
  132. run: ./frontends/src/noir/test_folder/compile.sh
  133. - name: Run examples tests
  134. run: cargo test --examples
  135. - name: Run examples
  136. run: cargo run --release --example 2>&1 | grep -E '^ ' | xargs -n1 cargo run --release --example
  137. fmt:
  138. if: github.event.pull_request.draft == false
  139. name: Rustfmt
  140. timeout-minutes: 30
  141. runs-on: ubuntu-latest
  142. steps:
  143. - uses: actions/checkout@v2
  144. - uses: actions-rs/toolchain@v1
  145. - uses: Swatinem/rust-cache@v2
  146. - run: rustup component add rustfmt
  147. - uses: actions-rs/cargo@v1
  148. with:
  149. command: fmt
  150. args: --all --check
  151. clippy:
  152. if: github.event.pull_request.draft == false
  153. name: Clippy lint checks
  154. runs-on: ubuntu-latest
  155. strategy:
  156. matrix:
  157. feature_set: [basic, wasm]
  158. include:
  159. - feature_set: basic
  160. features: --features default,light-test
  161. # We only want to test `frontends` package with `wasm` feature.
  162. - feature_set: wasm
  163. features: -p frontends --features wasm,parallel --target wasm32-unknown-unknown
  164. steps:
  165. - uses: actions/checkout@v2
  166. - uses: actions-rs/toolchain@v1
  167. with:
  168. components: clippy
  169. - uses: Swatinem/rust-cache@v2
  170. - name: Add target
  171. run: rustup target add wasm32-unknown-unknown
  172. - name: Run clippy
  173. uses: actions-rs/cargo@v1
  174. with:
  175. command: clippy
  176. args: --no-default-features ${{ matrix.features }} -- -D warnings
  177. typos:
  178. if: github.event.pull_request.draft == false
  179. name: Spell Check with Typos
  180. runs-on: ubuntu-latest
  181. steps:
  182. - uses: actions/checkout@v4
  183. - name: Use typos with config file
  184. uses: crate-ci/typos@master
  185. with:
  186. config: .github/workflows/typos.toml