Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Use preopen_dir handlers exposed in wasi-common #171

Merged
merged 1 commit into from
Jun 19, 2019
Merged

Use preopen_dir handlers exposed in wasi-common #171

merged 1 commit into from
Jun 19, 2019

Conversation

kubkon
Copy link
Member

@kubkon kubkon commented Jun 4, 2019

This PR depends on CraneStation/wasi-common#25, hence, before that one is merged, a CI failure is expected due to the dependence on functionality in wasi-common which hasn't made it to master yet.

@kubkon kubkon requested a review from sunfishcode June 4, 2019 06:08
@sunfishcode
Copy link
Member

CraneStation/wasi-common#25 is now merged!

@sunfishcode sunfishcode merged commit ce8912a into bytecodealliance:master Jun 19, 2019
@kubkon kubkon deleted the preopen_dir branch June 19, 2019 15:49
kubkon pushed a commit that referenced this pull request Nov 7, 2019
grishasobol pushed a commit to grishasobol/wasmtime that referenced this pull request Nov 29, 2021
…e#171)

* Removed byteorder now that from_le_bytes is stabilized

* Rust fmt
pchickey pushed a commit to pchickey/wasmtime that referenced this pull request May 16, 2023
This is just a rename, and it's not yet clear what shape wasi-cli-base
will ultimately take, but for now, it's useful to avoid confusion about
whether wasi-base is meant to be used by all WASI worlds. It is a base
for CLI-like worlds that have command-line args, environment variables,
and exit statuses, and not all WASI worlds will have those.
dhil added a commit to dhil/wasmtime that referenced this pull request May 15, 2024
avanhatt pushed a commit to wellesley-prog-sys/wasmtime that referenced this pull request Oct 23, 2024
Add a spec expression `(as <expr> <ty>)` to specify the type of a spec
expression inline. The syntax is motivated by SMT-LIB qualified
identifiers.

The motivation for this is the need to express register width
constraints in ASLp-derived specs.
avanhatt pushed a commit to wellesley-prog-sys/wasmtime that referenced this pull request Oct 23, 2024
Model the `Reg` type on AArch64 as unknown bitvector width.

Reverses bytecodealliance#108. The motivation for this is the need to model vector
intructions, where `Reg` is also used to represent ARM `Z` 128-bit
registers. The type inference problems that necessitated the 64-bit type
before have now been fixed by a combination of bytecodealliance#167 and bytecodealliance#171.

Updates avanhatt#46 avanhatt#34
avanhatt pushed a commit to wellesley-prog-sys/wasmtime that referenced this pull request Oct 23, 2024
Add a spec expression `(as <expr> <ty>)` to specify the type of a spec
expression inline. The syntax is motivated by SMT-LIB qualified
identifiers.

The motivation for this is the need to express register width
constraints in ASLp-derived specs.
avanhatt pushed a commit to wellesley-prog-sys/wasmtime that referenced this pull request Oct 23, 2024
Model the `Reg` type on AArch64 as unknown bitvector width.

Reverses bytecodealliance#108. The motivation for this is the need to model vector
intructions, where `Reg` is also used to represent ARM `Z` 128-bit
registers. The type inference problems that necessitated the 64-bit type
before have now been fixed by a combination of bytecodealliance#167 and bytecodealliance#171.

Updates avanhatt#46 avanhatt#34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants