github
/
cranelift
mirror of https://github.com/bytecodealliance/wasmtime.git
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
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.
12956 Commits
49 Branches
140 Tags
128 MiB
Tree: 95b08bb3cb
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '95b08bb3cb'
${ noResults }
cranelift/crates/cli-flags/Cargo.toml

33 lines
1.0 KiB
Raw Normal View History

bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
[package]
name = "wasmtime-cli-flags"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
version.workspace = true
authors.workspace = true
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
description = "Exposes common CLI flags used for running Wasmtime"
license = "Apache-2.0 WITH LLVM-exception"
repository = "https://github.com/bytecodealliance/wasmtime"
documentation = "https://docs.rs/wasmtime-cache/"
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
edition.workspace = true
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
Configure workspace lints, enable running some Clippy lints on CI (#7561) * Configure Rust lints at the workspace level This commit adds necessary configuration knobs to have lints configured at the workspace level in Wasmtime rather than the crate level. This uses a feature of Cargo first released with 1.74.0 (last week) of the `[workspace.lints]` table. This should help create a more consistent set of lints applied across all crates in our workspace in addition to possibly running select clippy lints on CI as well. * Move `unused_extern_crates` to the workspace level This commit configures a `deny` lint level for the `unused_extern_crates` lint to the workspace level rather than the previous configuration at the individual crate level. * Move `trivial_numeric_casts` to workspace level * Change workspace lint levels to `warn` CI will ensure that these don't get checked into the codebase and otherwise provide fewer speed bumps for in-process development. * Move `unstable_features` lint to workspace level * Move `unused_import_braces` lint to workspace level * Start running Clippy on CI This commit configures our CI to run `cargo clippy --workspace` for all merged PRs. Historically this hasn't been all the feasible due to the amount of configuration required to control the number of warnings on CI, but with Cargo's new `[lint]` table it's possible to have a one-liner to silence all lints from Clippy by default. This commit by default sets the `all` lint in Clippy to `allow` to by-default disable warnings from Clippy. The goal of this PR is to enable selective access to Clippy lints for Wasmtime on CI. * Selectively enable `clippy::cast_sign_loss` This would have fixed #7558 so try to head off future issues with that by warning against this situation in a few crates. This lint is still quite noisy though for Cranelift for example so it's not worthwhile at this time to enable it for the whole workspace. * Fix CI error prtest:full
12 months ago
[lints]
workspace = true
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
[dependencies]
Leverage Cargo's workspace inheritance feature (#4905) * Leverage Cargo's workspace inheritance feature This commit is an attempt to reduce the complexity of the Cargo manifests in this repository with Cargo's workspace-inheritance feature becoming stable in Rust 1.64.0. This feature allows specifying fields in the root workspace `Cargo.toml` which are then reused throughout the workspace. For example this PR shares definitions such as: * All of the Wasmtime-family of crates now use `version.workspace = true` to have a single location which defines the version number. * All crates use `edition.workspace = true` to have one default edition for the entire workspace. * Common dependencies are listed in `[workspace.dependencies]` to avoid typing the same version number in a lot of different places (e.g. the `wasmparser = "0.89.0"` is now in just one spot. Currently the workspace-inheritance feature doesn't allow having two different versions to inherit, so all of the Cranelift-family of crates still manually specify their version. The inter-crate dependencies, however, are shared amongst the root workspace. This feature can be seen as a method of "preprocessing" of sorts for Cargo manifests. This will help us develop Wasmtime but shouldn't have any actual impact on the published artifacts -- everything's dependency lists are still the same. * Fix wasi-crypto tests
2 years ago
anyhow = { workspace = true }
clap = { workspace = true }
Gate many CLI/Wasmtime features behind Cargo features (#7282) * Move `wasmtime explore` behind a Cargo feature Enable this Cargo feature by default, but enable building the CLI without the `explore` subcommand. * Move the `wast` subcommand behind a Cargo feature * Move support for `wat` behind a CLI feature This was already conditional in crates such as `wasmtime` and this makes it an optional dependency of the CLI as well. * Move CLI cache support behind a Cargo feature Additionally refactor `wasmtime-cli-flags` to not unconditionally pull in caching support by removing its `default` feature and appropriately enabling it from the CLI. * Move `rayon` behind an optional feature * Move `http-body-util` dependency behind `serve` feature * Add a Cargo feature for compiling out log statements This sets the static features of `log` and `tracing` to statically remove all log statements from the binary to cut down on binary size. * Move logging support behind a Cargo feature Enables statically removing logging support in addition to the previous compiling out log statements themselves. * Move demangling support behind a Cargo feature * Enable building the CLI without cranelift Compile out the `compile` subcommand for example. * Gate all profiling support behind one feature flag This commit moves vtune/jitdump support behind a single `profiling` feature flag that additionally includes the guest profiler dependencies now too. * Move support for core dumps behind a feature flag * Move addr2line behind a feature * Fix rebase * Document cargo features and a minimal build * Tidy up the source a bit * Rename compile-out-logging * Document disabling logging * Note the host architecture as well * Fix tests * Fix tests * Mention debuginfo stripping * Fix CI configuration for checking features * Fix book tests * Update lock file after rebase * Enable coredump feature by default
1 year ago
file-per-thread-logger = { workspace = true, optional = true }
tracing-subscriber = { workspace = true, optional = true }
rayon = { version = "1.5.0", optional = true }
Wasmtime: Add a `gc` cargo feature (#7975) * Wasmtime: Add a `gc` cargo feature This controls whether support for `ExternRef` and its associated deferred, reference-counting garbage collector is enabled at compile time or not. It will also be used for similarly for Wasmtime's full Wasm GC support as that gets added. * Add CI for `gc` Cargo feature * Cut down on the number of `#[cfg(feature = "gc")]`s outside the implementation of `[VM]ExternRef` * Fix wasmparser reference types configuration with GC disabled/enabled * More config fix * doc cfg * Make the dummy `VMExternRefActivationsTable` inhabited * Fix winch tests * final review bits * Enable wasmtime's gc cargo feature for the C API * Enable wasmtime's gc cargo feature from wasmtime-cli-flags * enable gc cargo feature in a couple other crates
9 months ago
wasmtime = { workspace = true, features = ["gc"] }
Add compatibility shims for Wasmtime 13 CLI (#7385) * Add compatibility shims for Wasmtime 13 CLI This commit introduces a compatibility shim for the Wasmtime 13 CLI and prior. The goal of this commit is to address concerns raised in #7336 and other locations as well. While the new CLI cannot be un-shipped at this point this PR attempts to ameliorate the situation somewhat through a few avenues: * A complete copy of the old CLI parser is now included in `wasmtime` by default. * The `WASMTIME_NEW_CLI=0` environment variable can force usage of the old CLI parser for the `run` and `compile` commands. * The `WASMTIME_NEW_CLI=1` environment variable can force usage of the new CLI parser. * Otherwise both the old and the new CLI parser are executed. Depending on the result one is selected to be executed, possibly with a warning printed. * If both CLI parsers succeed but produce the same result, then no warning is emitted and execution continues as usual. * If both CLI parsers succeed but produce different results then a warning is emitted indicating this. The warning points to #7384 which has further examples of how to squash the warning. The warning also mentions the above env var to turn the warning off. In this situation the old semantics are used at this time instead of the new semantics. It's intended that eventually this will change in the future. * If the new CLI succeeds and the old CLI fails then the new semantics are executed without warning. * If the old CLI succeeds and the new CLI fails then a warning is issued and the old semantics are used. * If both the old and the new CLI fail to parse then the error message for the new CLI is emitted. Note that this doesn't add up to a perfect transition. The hope is that most of the major cases of change at the very least have something printed. My plan is to land this on `main` and then backport it to the 14.0.0 branch as a 14.0.3 release. * Wordsmith messages * Update messages * More wording updates * Fix grammar * More updates
1 year ago
humantime = { workspace = true }
bench-api: configure execution with a flags string (#4096) As discussed previously, we need a way to be able to configure Wasmtime when running it in the Sightglass benchmark infrastructure. The easiest way to do this seemed to be to pass a string from Sightglass to the `bench-api` library and parse this in the same way that Wasmtime parses its CLI flags. The structure that contains these flags is `CommonOptions`, so it has been moved to its own crate to be depended on by both `wasmtime-cli` and `wasmtime-bench-api`. Also, this change adds an externally-visible function for parsing a string into `CommonOptions`, which is used for configuring an engine.
3 years ago
[features]
pooling-allocator = []
Fix testing cli-flags crate with component-model feature (#6831) Not used on CI yet but it's part of an upcoming change I figured I'd split out.
1 year ago
component-model = ["wasmtime/component-model"]
Gate many CLI/Wasmtime features behind Cargo features (#7282) * Move `wasmtime explore` behind a Cargo feature Enable this Cargo feature by default, but enable building the CLI without the `explore` subcommand. * Move the `wast` subcommand behind a Cargo feature * Move support for `wat` behind a CLI feature This was already conditional in crates such as `wasmtime` and this makes it an optional dependency of the CLI as well. * Move CLI cache support behind a Cargo feature Additionally refactor `wasmtime-cli-flags` to not unconditionally pull in caching support by removing its `default` feature and appropriately enabling it from the CLI. * Move `rayon` behind an optional feature * Move `http-body-util` dependency behind `serve` feature * Add a Cargo feature for compiling out log statements This sets the static features of `log` and `tracing` to statically remove all log statements from the binary to cut down on binary size. * Move logging support behind a Cargo feature Enables statically removing logging support in addition to the previous compiling out log statements themselves. * Move demangling support behind a Cargo feature * Enable building the CLI without cranelift Compile out the `compile` subcommand for example. * Gate all profiling support behind one feature flag This commit moves vtune/jitdump support behind a single `profiling` feature flag that additionally includes the guest profiler dependencies now too. * Move support for core dumps behind a feature flag * Move addr2line behind a feature * Fix rebase * Document cargo features and a minimal build * Tidy up the source a bit * Rename compile-out-logging * Document disabling logging * Note the host architecture as well * Fix tests * Fix tests * Mention debuginfo stripping * Fix CI configuration for checking features * Fix book tests * Update lock file after rebase * Enable coredump feature by default
1 year ago
cache = ["wasmtime/cache"]
parallel-compilation = ["wasmtime/parallel-compilation", "dep:rayon"]
logging = ["dep:file-per-thread-logger", "dep:tracing-subscriber"]
cranelift = ["wasmtime/cranelift"]
coredump = ["wasmtime/coredump"]
Gate support for the wasm `threads` proposal behind a Cargo feature (#8260) * Gate support for the wasm `threads` proposal behind a Cargo feature This commit moves support for the `threads` proposal behind a new on-by-default Cargo feature: `threads`. This is intended to support building Wasmtime with fewer runtime dependencies such as those required for the atomic operations on memories. This additionally adds the `gc` feature in a few missing places too. * Fix compile of C API without threads
7 months ago
gc = ["wasmtime/gc"]
threads = ["wasmtime/threads"]