libbz2 (bzip2 compression) bindings for Rust
A streaming audio player class (AudioStreamer) for Mac OS X and iPhone.
A buffered I/O stream for Rust
ar in Rust
are you or are you not a tty?
Compiler infrastructure and toolchain library for WebAssembly, in C++
WIP
Original libbz2 ruby C bindings from Guy Decoux, with some new love
alexcrichton/1password-teams-open-source 0
Get a free 1Password Teams membership for your open source project
PR merged bytecodealliance/wasmtime
The previous implementation of Imm12::maybe_from_u64 did not match the constant values 0xfff or 0xfff000, even though those are expressible in the aarch64 12-bit immediate format.
Also the explicit test for 0 was unnecessary; it's a valid example of all bits outside the least-significant 12 bits being 0.
pr closed time in 3 days
push eventbytecodealliance/wasmtime
commit sha 176935e75e4f3c65c915772b3e145438b933a4b6
aarch64: Use Imm12 in more cases (#6512) The previous implementation of Imm12::maybe_from_u64 did not match the constant values 0xfff or 0xfff000, even though those are expressible in the aarch64 12-bit immediate format. Also the explicit test for 0 was unnecessary; it's a valid example of all bits outside the least-significant 12 bits being 0.
push time in 3 days
push eventalexcrichton/wasmtime
commit sha 4b096990d31138d2cec12363f575f36535933353
Fix restoration during panic
push time in 3 days
pull request commentbytecodealliance/wasmtime
Fix a soundness issue with the component model and async
I definitely agree with the separation of types and re-wording of things, done now 👍
comment created time in 3 days
push eventalexcrichton/wasmtime
commit sha b5f780dc871dc0afc06ab9fa9750884d84017e64
Review comments
push time in 3 days
Pull request review commentbytecodealliance/wasm-tools
feat(wit-parser): add parser for include
impl<'a> Resolver<'a> { IndexMap::new() }); let id = *deps.entry(name.name).or_insert_with(|| {- log::trace!(- "creating an interface for foreign dep: {}/{}",- id.package_name(),- name.name- );- self.alloc_interface(name.span)+ match world_or_iface {+ WorldOrInterface::World => {+ log::trace!(+ "creating a world for foreign dep: {}/{}",+ id.package_name(),+ name.name+ );+ AstItem::World(self.alloc_world(name.span, true))+ }+ WorldOrInterface::Interface => {+ log::trace!(+ "creating an interface for foreign dep: {}/{}",+ id.package_name(),+ name.name+ );+ AstItem::Interface(self.alloc_interface(name.span))+ }+ WorldOrInterface::Unknown => {
Could this arm be merged with the interface arm with the comment explaining that "unknown" is equivalent to an interface at this time?
comment created time in 3 days
Pull request review commentbytecodealliance/wasm-tools
feat(wit-parser): add parser for include
impl<'a> Resolver<'a> { Ok(()) } + /// For each name in the `include`, resolve the path of the include, add it to the self.includes+ fn resolve_include(&mut self, owner: TypeOwner, i: &ast::Include<'a>) -> Result<()> {+ let (item, name, span) = self.resolve_ast_item_path(&i.from)?;+ let include_from = self.extract_world_from_item(&item, &name, span)?;+ self.foreign_world_spans.push(span);
I'm still not quite sure, but what is this for?
comment created time in 3 days
Pull request review commentbytecodealliance/wasm-tools
feat(wit-parser): add parser for include
impl Remap { } }); }++ fn resolve_include(+ &self,+ world: &mut World,+ include_world: WorldId,+ names: &[IncludeName],+ span: Span,+ resolve: &Resolve,+ ) -> Result<()> {+ let include_world_id = self.worlds[include_world.index()];+ let include_world = &resolve.worlds[include_world_id];++ // copy the imports and exports from the included world into the current world+ for import in include_world.imports.iter() {+ let name = import.0;+ match name {+ WorldKey::Name(n) => {+ let n = if let Some(found) = names+ .into_iter()+ .find(|include_name| include_name.name == n.clone())+ {+ found.as_.clone()+ } else {+ n.clone()+ };++ let prev = world+ .imports+ .insert(WorldKey::Name(n.clone()), import.1.clone());+ if prev.is_some() {+ bail!(Error {+ msg: format!("import of `{}` shadows previously imported items", n),+ span,+ })+ }+ }+ i => {+ world.imports.insert(i.clone(), import.1.clone());+ }+ };+ }++ for export in include_world.exports.iter() {+ let name = export.0;+ match name {+ WorldKey::Name(n) => {+ let n = if let Some(found) = names+ .into_iter()+ .find(|include_name| include_name.name == n.clone())+ {+ found.as_.clone()+ } else {+ n.clone()+ };+ let prev = world+ .exports+ .insert(WorldKey::Name(n.clone()), export.1.clone());+ if prev.is_some() {+ bail!(Error {+ msg: format!("export of `{}` shadows previously exported items", n),+ span,+ })+ }+ }+ i => {+ world.exports.insert(i.clone(), export.1.clone());+ }+ }+ }
The body of this loop I think is more-or-less the same as the import one, so could this be refactored to share code? Additionally could the non-name based insert assert! that the item, if previously present, is the same as the one inserted?
comment created time in 3 days
PR closed bytecodealliance/wasmtime
<!-- Please make sure you include the following information:
-
If this work has been discussed elsewhere, please include a link to that conversation. If it was discussed in an issue, just mention "issue #...".
-
Explain why this change is needed. If the details are in an issue already, this can be brief.
Our development process is documented in the Wasmtime book: https://docs.wasmtime.dev/contributing-development-process.html
Please ensure all communication follows the code of conduct: https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md -->
pr closed time in 3 days
Pull request review commentbytecodealliance/wasmtime
x64: Avoid using `movddup` without SSSE3
block0(v0: f64): ; pushq %rbp ; movq %rsp, %rbp ; block0:-; movddup %xmm0, %xmm0+; pshufd $68, %xmm0, %xmm0
Ah yes this is intended, I ended up changing the translation of splat from the previous movddup to pshufd in the default case. I did that because it seems it's what LLVM does for me in Rust, but I don't know if there's a specific reason to use movddup vs pshufd (happy to add lowerings for both of course)
comment created time in 3 days
push eventalexcrichton/wasmtime
commit sha d397b5183680ec6f120e02ab23bbb2fef62415a7
Explicitly disable fail-fast
push time in 3 days
delete branch bytecodealliance/wasmtime
delete branch : upgrade-file-per-thread-logger
delete time in 3 days
push eventbytecodealliance/wasmtime
commit sha 112e52d722a33aace1fc0c4df2bd5d0d37f7e27c
Upgrade file per thread logger to 0.2.0 (#6503) * Upgrade file-per-thread-logger to v0.2.0 Signed-off-by: Benjamin Bouvier <public@benj.me> * Update audits too Signed-off-by: Benjamin Bouvier <public@benj.me> --------- Signed-off-by: Benjamin Bouvier <public@benj.me>
push time in 3 days
issue closedbytecodealliance/wasmtime
CI test suite is incompatible with `RUST_LOG=trace`
Setting RUST_LOG=trace in CI tests, e.g. e3cf96200
consistently causes panic in tests:
thread 'worker #1' panicked at 'already mutably borrowed: BorrowError', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/file-per-thread-logger-0.1.6/src/lib.rs:117:23
stack backtrace:
0: rust_begin_unwind
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
1: core::panicking::panic_fmt
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
2: core::result::unwrap_failed
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/result.rs:1750:5
3: core::result::Result<T,E>::expect
4: core::cell::RefCell<T>::borrow
5: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log::{{closure}}
6: std::thread::local::LocalKey<T>::try_with
7: std::thread::local::LocalKey<T>::with
8: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log
9: log::__private_api_log
10: cranelift_codegen::isa::aarch64::inst::emit::mem_finalize
11: cranelift_codegen::isa::aarch64::inst::<impl cranelift_codegen::isa::aarch64::lower::isle::generated_code::MInst>::print_with_state
12: cranelift_codegen::isa::aarch64::inst::emit::<impl cranelift_codegen::machinst::MachInstEmit for cranelift_codegen::isa::aarch64::lower::isle::generated_code::MInst>::pretty_print_inst
13: <cranelift_codegen::machinst::vcode::VCode<I> as core::fmt::Debug>::fmt
14: core::fmt::write
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:1232:17
15: <core::fmt::Arguments as core::fmt::Display>::fmt
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:559:9
16: <&T as core::fmt::Display>::fmt
17: core::fmt::write
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:1232:17
18: std::io::Write::write_fmt
19: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log::{{closure}}
20: std::thread::local::LocalKey<T>::try_with
21: std::thread::local::LocalKey<T>::with
22: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log
23: log::__private_api_log
24: cranelift_codegen::machinst::lower::Lower<I>::lower
25: cranelift_codegen::machinst::compile::compile
26: cranelift_codegen::isa::aarch64::AArch64Backend::compile_vcode
27: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::isa::TargetIsa>::compile_function
28: cranelift_codegen::context::Context::compile_stencil
29: cranelift_codegen::context::Context::compile
30: <cranelift_filetests::test_compile::TestCompile as cranelift_filetests::subtest::SubTest>::run
31: cranelift_filetests::subtest::SubTest::run_target
32: cranelift_filetests::runone::run
33: cranelift_filetests::concurrent::worker_thread::{{closure}}::{{closure}}
34: std::panicking::try::do_call
35: __rust_try
36: std::panicking::try
37: std::panic::catch_unwind
38: cranelift_filetests::concurrent::worker_thread::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
FAIL filetests/filetests/isa/aarch64/dynamic-slot.clif: panicked in worker #1: already mutably borrowed: BorrowError
thread 'worker #1' panicked at 'already mutably borrowed: BorrowError', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/file-per-thread-logger-0.1.6/src/lib.rs:117:23
stack backtrace:
0: rust_begin_unwind
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
1: core::panicking::panic_fmt
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
2: core::result::unwrap_failed
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/result.rs:1750:5
3: core::result::Result<T,E>::expect
4: core::cell::RefCell<T>::borrow
5: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log::{{closure}}
6: std::thread::local::LocalKey<T>::try_with
7: std::thread::local::LocalKey<T>::with
8: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log
9: log::__private_api_log
10: cranelift_codegen::isa::aarch64::inst::emit::mem_finalize
11: cranelift_codegen::isa::aarch64::inst::<impl cranelift_codegen::isa::aarch64::lower::isle::generated_code::MInst>::print_with_state
12: cranelift_codegen::isa::aarch64::inst::emit::<impl cranelift_codegen::machinst::MachInstEmit for cranelift_codegen::isa::aarch64::lower::isle::generated_code::MInst>::pretty_print_inst
13: <cranelift_codegen::machinst::vcode::VCode<I> as core::fmt::Debug>::fmt
14: core::fmt::write
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:1232:17
15: <core::fmt::Arguments as core::fmt::Display>::fmt
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:559:9
16: <&T as core::fmt::Display>::fmt
17: core::fmt::write
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:1232:17
18: std::io::Write::write_fmt
19: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log::{{closure}}
20: std::thread::local::LocalKey<T>::try_with
21: std::thread::local::LocalKey<T>::with
22: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log
23: log::__private_api_log
24: cranelift_codegen::machinst::lower::Lower<I>::lower
25: cranelift_codegen::machinst::compile::compile
26: cranelift_codegen::isa::aarch64::AArch64Backend::compile_vcode
27: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::isa::TargetIsa>::compile_function
28: cranelift_codegen::context::Context::compile_stencil
31: cranelift_filetests::subtest::SubTest::run_target
32: cranelift_filetests::runone::run
33: cranelift_filetests::concurrent::worker_thread::{{closure}}::{{closure}}
34: std::panicking::try::do_call
35: __rust_try
36: std::panicking::try
37: std::panic::catch_unwind
38: cranelift_filetests::concurrent::worker_thread::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
FAIL filetests/filetests/isa/aarch64/reftypes.clif: panicked in worker #0: already mutably borrowed: BorrowError
thread 'worker #1' panicked at 'already mutably borrowed: BorrowError', /home/runner/.cargo/registry/src/index.crates.io-6f17d22bba15001f/file-per-thread-logger-0.1.6/src/lib.rs:117:23
stack backtrace:
0: rust_begin_unwind
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/std/src/panicking.rs:579:5
1: core::panicking::panic_fmt
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/panicking.rs:64:14
2: core::result::unwrap_failed
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/result.rs:1750:5
3: core::result::Result<T,E>::expect
4: core::cell::RefCell<T>::borrow
5: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log::{{closure}}
6: std::thread::local::LocalKey<T>::try_with
7: std::thread::local::LocalKey<T>::with
8: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log
9: log::__private_api_log
10: cranelift_codegen::isa::aarch64::inst::emit::mem_finalize
11: cranelift_codegen::isa::aarch64::inst::<impl cranelift_codegen::isa::aarch64::lower::isle::generated_code::MInst>::print_with_state
12: cranelift_codegen::isa::aarch64::inst::emit::<impl cranelift_codegen::machinst::MachInstEmit for cranelift_codegen::isa::aarch64::lower::isle::generated_code::MInst>::pretty_print_inst
13: <cranelift_codegen::machinst::vcode::VCode<I> as core::fmt::Debug>::fmt
14: core::fmt::write
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:1232:17
15: <core::fmt::Arguments as core::fmt::Display>::fmt
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:559:9
16: <&T as core::fmt::Display>::fmt
17: core::fmt::write
at /rustc/84c898d65adf2f39a5a98507f1fe0ce10a2b8dbc/library/core/src/fmt/mod.rs:1232:17
18: std::io::Write::write_fmt
19: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log::{{closure}}
20: std::thread::local::LocalKey<T>::try_with
21: std::thread::local::LocalKey<T>::with
22: <file_per_thread_logger::FilePerThreadLogger as log::Log>::log
23: log::__private_api_log
24: cranelift_codegen::machinst::lower::Lower<I>::lower
25: cranelift_codegen::machinst::compile::compile
26: cranelift_codegen::isa::aarch64::AArch64Backend::compile_vcode
27: <cranelift_codegen::isa::aarch64::AArch64Backend as cranelift_codegen::isa::TargetIsa>::compile_function
28: cranelift_codegen::context::Context::compile_stencil
29: cranelift_codegen::context::Context::compile
30: <cranelift_filetests::test_compile::TestCompile as cranelift_filetests::subtest::SubTest>::run
31: cranelift_filetests::subtest::SubTest::run_target
32: cranelift_filetests::runone::run
33: cranelift_filetests::concurrent::worker_thread::{{closure}}::{{closure}}
34: std::panicking::try::do_call
35: __rust_try
36: std::panicking::try
37: std::panic::catch_unwind
38: cranelift_filetests::concurrent::worker_thread::{{closure}}
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
FAIL filetests/filetests/egraph/issue-5716.clif: panicked in worker #1: already mutably borrowed: BorrowError
1218 tests
Error: 5 failures
error: test failed, to rerun pass `-p cranelift-tools --test filetests`
closed time in 3 days
rvolosatovs
PR merged bytecodealliance/wasmtime
This should fix https://github.com/bytecodealliance/wasmtime/issues/6456. @rvolosatovs could you confirm this please?
pr closed time in 3 days
pull request commentbytecodealliance/wasmtime
I'm opening this to get an "official" run of everything with 1.70.0 that can in theory be investigated.
comment created time in 3 days
PR opened bytecodealliance/wasmtime
<!-- Please make sure you include the following information:
-
If this work has been discussed elsewhere, please include a link to that conversation. If it was discussed in an issue, just mention "issue #...".
-
Explain why this change is needed. If the details are in an issue already, this can be brief.
Our development process is documented in the Wasmtime book: https://docs.wasmtime.dev/contributing-development-process.html
Please ensure all communication follows the code of conduct: https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md -->
pr created time in 3 days
issue commentWebAssembly/relaxed-simd
Codegen of i16x8.relaxed_laneselect
For me I still don't fully understand the motivation for the existence of this instruction. It seems to be like there's three possible motivations, and forgive me for possible erroneously extrapolating here and please correct me if I'm wrong.
- There's more performant lowering than the deterministic alternative
v128.bitselecton some platforms. That's the case fori8x16,i32x4, andi64x2variants ofrelaxed_laneselect, or so I assume given a count-the-instructions metric. This isn't at least obviously the case fori16x8though wherev128.bitselectis apand + pandn + porcombo. I'll admit though that I know count-the-instructions metrics are not always accurate, so is the combo you're proposing @penzn noticeably better than thev128.bitselectcombo? - It's symmetrical to have an
i16x8variant when the other variants are present. I mentioned above how I don't personally agree with this, but that's not to say that this argument can't be made. I'm not sure if this symmetry angle has been used to motivation other instructions for example. - It's a pain to remove instructions at this stage of the proposal. I don't want to diminish the work necessary to remove it or sweep it under the rug, I do think it's a real cost to eat. That being said if this is the motivation for keeping it then I do think it's worth being honest that this is the case.
My personal take is that none of those motivations justify the existence of the instruction, but I recognize I may very well be missing something crucial! (and that I'm just one person and this is a pretty minor issue all things concerned)
comment created time in 3 days
issue commentbytecodealliance/wasmtime
Crash when async yielding is enabled
Ok I believe that https://github.com/bytecodealliance/wasmtime/pull/6509 should address this issue for now
comment created time in 3 days
pull request commentbytecodealliance/wasmtime
Fix a soundness issue with the component model and async
I'll note that I had a number of false starts in attempting to solve this issue. First I thought that this only needed a push/pop around calls to cabi_realloc in the component model, but that wasn't correct because that only works for import-based calls to realloc, not export-based calls. I then wrote a test to expose the flaw with that strategy.
Next I thought that it would be possible to not actually maintain the entire linked list of activations and instead have a fiber have its own linked list which replaces the current thread's linked list when it resumes and swaps it back out when it suspends. This however does not work because a complete list of activations is required to correctly perform GC, so I wrote a test to expose that bug.
Finally I settled on this solution, which is at least sufficient for all the above scenarios. I'm not 100% sure it's the end-all-be-all, so extra care in review would be appreciated!
comment created time in 3 days
PR opened bytecodealliance/wasmtime
This commit addresses https://github.com/bytecodealliance/wasmtime/issues/6493 by fixing a soundness issue with the async
implementation of the component model. This issue has been presence
since the inception of the addition of async support to the component
model and doesn't represent a recent regression. The underlying problem
is that one of the base assumptions of the trap handling code is that
there's only one single activation in TLS that needs to be pushed/popped
when a stack is switched (e.g. a fiber is switched to or from). In the
case of the component model there might be two activations: one for an
invocation of a component function and then a second for an invocation
of a realloc function to return results back to wasm (e.g. in the case
an imported function returns a list).
This problem is fixed by changing how TLS is managed in the presence of fibers. Previously when a fiber was suspended it would pop a single activation from the top of the stack and save that to get pushed when the fiber was resumed. This has the benefit of maintaining an entire linked list of activations for the current thread but has the problem above where it doesn't handle a fiber with multiple activations on it. Instead now TLS management is done when a fiber is resumed instead of suspended. Instead of pushing/popping a single activation the entire linked list of activations is tracked for a particular fiber and stored within the fiber itself. In this manner resuming a fiber will push all activations onto the current thread and suspending a fiber will pop all activations for the fiber (and store them as a new linked list in the fiber's state itself).
This end result is that all activations on a fiber should now be managed correctly, regardless of how many there are. The main downside of this commit is that fiber suspension and resumption is more complicated, but the hope there is that fiber suspension typically corresponds with I/O not being ready or similar so the order of magnitude of TLS operations isn't too significant compared to the I/O overhead.
pr created time in 3 days