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.
13545 Commits
49 Branches
140 Tags
128 MiB
Tree: a6048e5425
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from 'a6048e5425'
${ noResults }
cranelift/tests/misc_testsuite/component-model/simple.wast

43 lines
771 B
Raw Normal View History

Initial skeleton of some component model processing (#4005) * Initial skeleton of some component model processing This commit is the first of what will likely be many to implement the component model proposal in Wasmtime. This will be structured as a series of incremental commits, most of which haven't been written yet. My hope is to make this incremental and over time to make this easier to review and easier to test each step in isolation. Here much of the skeleton of how components are going to work in Wasmtime is sketched out. This is not a complete implementation of the component model so it's not all that useful yet, but some things you can do are: * Process the type section into a representation amenable for working with in Wasmtime. * Process the module section and register core wasm modules. * Process the instance section for core wasm modules. * Process core wasm module imports. * Process core wasm instance aliasing. * Ability to compile a component with core wasm embedded. * Ability to instantiate a component with no imports. * Ability to get functions from this component. This is already starting to diverge from the previous module linking representation where a `Component` will try to avoid unnecessary metadata about the component and instead internally only have the bare minimum necessary to instantiate the module. My hope is we can avoid constructing most of the index spaces during instantiation only for it to all ge thrown away. Additionally I'm predicting that we'll need to see through processing where possible to know how to generate adapters and where they are fused. At this time you can't actually call a component's functions, and that's the next PR that I would like to make. * Add tests for the component model support This commit uses the recently updated wasm-tools crates to add tests for the component model added in the previous commit. This involved updating the `wasmtime-wast` crate for component-model changes. Currently the component support there is quite primitive, but enough to at least instantiate components and verify the internals of Wasmtime are all working correctly. Additionally some simple tests for the embedding API have also been added.
3 years ago
(component)
(component
Update wasm-tools crates (#4246) This commit updates the wasm-tools family of crates, notably pulling in the refactorings and updates from bytecodealliance/wasm-tools#621 for the latest iteration of the component model. This commit additionally updates all support for the component model for these changes, notably: * Many bits and pieces of type information was refactored. Many `FooTypeIndex` namings are now `TypeFooIndex`. Additionally there is now `TypeIndex` as well as `ComponentTypeIndex` for the two type index spaces in a component. * A number of new sections are now processed to handle the core and component variants. * Internal maps were split such as the `funcs` map into `component_funcs` and `funcs` (same for `instances`). * Canonical options are now processed individually instead of one bulk `into` definition. Overall this was not a major update to the internals of handling the component model in Wasmtime. Instead this was mostly a surface-level refactoring to make sure that everything lines up with the new binary format for components. * All text syntax used in tests was updated to the new syntax.
2 years ago
(core module)
Initial skeleton of some component model processing (#4005) * Initial skeleton of some component model processing This commit is the first of what will likely be many to implement the component model proposal in Wasmtime. This will be structured as a series of incremental commits, most of which haven't been written yet. My hope is to make this incremental and over time to make this easier to review and easier to test each step in isolation. Here much of the skeleton of how components are going to work in Wasmtime is sketched out. This is not a complete implementation of the component model so it's not all that useful yet, but some things you can do are: * Process the type section into a representation amenable for working with in Wasmtime. * Process the module section and register core wasm modules. * Process the instance section for core wasm modules. * Process core wasm module imports. * Process core wasm instance aliasing. * Ability to compile a component with core wasm embedded. * Ability to instantiate a component with no imports. * Ability to get functions from this component. This is already starting to diverge from the previous module linking representation where a `Component` will try to avoid unnecessary metadata about the component and instead internally only have the bare minimum necessary to instantiate the module. My hope is we can avoid constructing most of the index spaces during instantiation only for it to all ge thrown away. Additionally I'm predicting that we'll need to see through processing where possible to know how to generate adapters and where they are fused. At this time you can't actually call a component's functions, and that's the next PR that I would like to make. * Add tests for the component model support This commit uses the recently updated wasm-tools crates to add tests for the component model added in the previous commit. This involved updating the `wasmtime-wast` crate for component-model changes. Currently the component support there is quite primitive, but enough to at least instantiate components and verify the internals of Wasmtime are all working correctly. Additionally some simple tests for the embedding API have also been added.
3 years ago
)
(component
Update wasm-tools crates (#4246) This commit updates the wasm-tools family of crates, notably pulling in the refactorings and updates from bytecodealliance/wasm-tools#621 for the latest iteration of the component model. This commit additionally updates all support for the component model for these changes, notably: * Many bits and pieces of type information was refactored. Many `FooTypeIndex` namings are now `TypeFooIndex`. Additionally there is now `TypeIndex` as well as `ComponentTypeIndex` for the two type index spaces in a component. * A number of new sections are now processed to handle the core and component variants. * Internal maps were split such as the `funcs` map into `component_funcs` and `funcs` (same for `instances`). * Canonical options are now processed individually instead of one bulk `into` definition. Overall this was not a major update to the internals of handling the component model in Wasmtime. Instead this was mostly a surface-level refactoring to make sure that everything lines up with the new binary format for components. * All text syntax used in tests was updated to the new syntax.
2 years ago
(core module)
(core module)
(core module)
Initial skeleton of some component model processing (#4005) * Initial skeleton of some component model processing This commit is the first of what will likely be many to implement the component model proposal in Wasmtime. This will be structured as a series of incremental commits, most of which haven't been written yet. My hope is to make this incremental and over time to make this easier to review and easier to test each step in isolation. Here much of the skeleton of how components are going to work in Wasmtime is sketched out. This is not a complete implementation of the component model so it's not all that useful yet, but some things you can do are: * Process the type section into a representation amenable for working with in Wasmtime. * Process the module section and register core wasm modules. * Process the instance section for core wasm modules. * Process core wasm module imports. * Process core wasm instance aliasing. * Ability to compile a component with core wasm embedded. * Ability to instantiate a component with no imports. * Ability to get functions from this component. This is already starting to diverge from the previous module linking representation where a `Component` will try to avoid unnecessary metadata about the component and instead internally only have the bare minimum necessary to instantiate the module. My hope is we can avoid constructing most of the index spaces during instantiation only for it to all ge thrown away. Additionally I'm predicting that we'll need to see through processing where possible to know how to generate adapters and where they are fused. At this time you can't actually call a component's functions, and that's the next PR that I would like to make. * Add tests for the component model support This commit uses the recently updated wasm-tools crates to add tests for the component model added in the previous commit. This involved updating the `wasmtime-wast` crate for component-model changes. Currently the component support there is quite primitive, but enough to at least instantiate components and verify the internals of Wasmtime are all working correctly. Additionally some simple tests for the embedding API have also been added.
3 years ago
)
(component
Update wasm-tools crates (#4246) This commit updates the wasm-tools family of crates, notably pulling in the refactorings and updates from bytecodealliance/wasm-tools#621 for the latest iteration of the component model. This commit additionally updates all support for the component model for these changes, notably: * Many bits and pieces of type information was refactored. Many `FooTypeIndex` namings are now `TypeFooIndex`. Additionally there is now `TypeIndex` as well as `ComponentTypeIndex` for the two type index spaces in a component. * A number of new sections are now processed to handle the core and component variants. * Internal maps were split such as the `funcs` map into `component_funcs` and `funcs` (same for `instances`). * Canonical options are now processed individually instead of one bulk `into` definition. Overall this was not a major update to the internals of handling the component model in Wasmtime. Instead this was mostly a surface-level refactoring to make sure that everything lines up with the new binary format for components. * All text syntax used in tests was updated to the new syntax.
2 years ago
(core module
Initial skeleton of some component model processing (#4005) * Initial skeleton of some component model processing This commit is the first of what will likely be many to implement the component model proposal in Wasmtime. This will be structured as a series of incremental commits, most of which haven't been written yet. My hope is to make this incremental and over time to make this easier to review and easier to test each step in isolation. Here much of the skeleton of how components are going to work in Wasmtime is sketched out. This is not a complete implementation of the component model so it's not all that useful yet, but some things you can do are: * Process the type section into a representation amenable for working with in Wasmtime. * Process the module section and register core wasm modules. * Process the instance section for core wasm modules. * Process core wasm module imports. * Process core wasm instance aliasing. * Ability to compile a component with core wasm embedded. * Ability to instantiate a component with no imports. * Ability to get functions from this component. This is already starting to diverge from the previous module linking representation where a `Component` will try to avoid unnecessary metadata about the component and instead internally only have the bare minimum necessary to instantiate the module. My hope is we can avoid constructing most of the index spaces during instantiation only for it to all ge thrown away. Additionally I'm predicting that we'll need to see through processing where possible to know how to generate adapters and where they are fused. At this time you can't actually call a component's functions, and that's the next PR that I would like to make. * Add tests for the component model support This commit uses the recently updated wasm-tools crates to add tests for the component model added in the previous commit. This involved updating the `wasmtime-wast` crate for component-model changes. Currently the component support there is quite primitive, but enough to at least instantiate components and verify the internals of Wasmtime are all working correctly. Additionally some simple tests for the embedding API have also been added.
3 years ago
(func (export "a") (result i32) i32.const 0)
(func (export "b") (result i64) i64.const 0)
)
Update wasm-tools crates (#4246) This commit updates the wasm-tools family of crates, notably pulling in the refactorings and updates from bytecodealliance/wasm-tools#621 for the latest iteration of the component model. This commit additionally updates all support for the component model for these changes, notably: * Many bits and pieces of type information was refactored. Many `FooTypeIndex` namings are now `TypeFooIndex`. Additionally there is now `TypeIndex` as well as `ComponentTypeIndex` for the two type index spaces in a component. * A number of new sections are now processed to handle the core and component variants. * Internal maps were split such as the `funcs` map into `component_funcs` and `funcs` (same for `instances`). * Canonical options are now processed individually instead of one bulk `into` definition. Overall this was not a major update to the internals of handling the component model in Wasmtime. Instead this was mostly a surface-level refactoring to make sure that everything lines up with the new binary format for components. * All text syntax used in tests was updated to the new syntax.
2 years ago
(core module
Initial skeleton of some component model processing (#4005) * Initial skeleton of some component model processing This commit is the first of what will likely be many to implement the component model proposal in Wasmtime. This will be structured as a series of incremental commits, most of which haven't been written yet. My hope is to make this incremental and over time to make this easier to review and easier to test each step in isolation. Here much of the skeleton of how components are going to work in Wasmtime is sketched out. This is not a complete implementation of the component model so it's not all that useful yet, but some things you can do are: * Process the type section into a representation amenable for working with in Wasmtime. * Process the module section and register core wasm modules. * Process the instance section for core wasm modules. * Process core wasm module imports. * Process core wasm instance aliasing. * Ability to compile a component with core wasm embedded. * Ability to instantiate a component with no imports. * Ability to get functions from this component. This is already starting to diverge from the previous module linking representation where a `Component` will try to avoid unnecessary metadata about the component and instead internally only have the bare minimum necessary to instantiate the module. My hope is we can avoid constructing most of the index spaces during instantiation only for it to all ge thrown away. Additionally I'm predicting that we'll need to see through processing where possible to know how to generate adapters and where they are fused. At this time you can't actually call a component's functions, and that's the next PR that I would like to make. * Add tests for the component model support This commit uses the recently updated wasm-tools crates to add tests for the component model added in the previous commit. This involved updating the `wasmtime-wast` crate for component-model changes. Currently the component support there is quite primitive, but enough to at least instantiate components and verify the internals of Wasmtime are all working correctly. Additionally some simple tests for the embedding API have also been added.
3 years ago
(func (export "c") (result f32) f32.const 0)
(func (export "d") (result f64) f64.const 0)
)
)
Add support for nested components (#4285) * Add support for nested components This commit is an implementation of a number of features of the component model including: * Defining nested components * Outer aliases to components and modules * Instantiating nested components The implementation here is intended to be a foundational pillar of Wasmtime's component model support since recursion and nested components are the bread-and-butter of the component model. At a high level the intention for the component model implementation in Wasmtime has long been that the recursive nature of components is "erased" at compile time to something that's more optimized and efficient to process. This commit ended up exemplifying this quite well where the vast majority of the internal changes here are in the "compilation" phase of a component rather than the runtime instantiation phase. The support in the `wasmtime` crate, the runtime instantiation support, only had minor updates here while the internals of translation have seen heavy updates. The `translate` module was greatly refactored here in this commit. Previously it would, as a component is parsed, create a final `Component` to hand off to trampoline compilation and get persisted at runtime. Instead now it's a thin layer over `wasmparser` which simply records a list of `LocalInitializer` entries for how to instantiate the component and its index spaces are built. This internal representation of the instantiation of a component is pretty close to the binary format intentionally. Instead of performing dataflow legwork the `translate` phase of a component is now responsible for two primary tasks: 1. All components and modules are discovered within a component. They're assigned `Static{Component,Module}Index` depending on where they're found and a `{Module,}Translation` is prepared for each one. This "flattens" the recursive structure of the binary into an indexed list processable later. 2. The lexical scope of components is managed here to implement outer module and component aliases. This is a significant design implementation because when closing over an outer component or module that item may actually be imported or something like the result of a previous instantiation. This means that the capture of modules and components is both a lexical concern as well as a runtime concern. The handling of the "runtime" bits are handled in the next phase of compilation. The next and currently final phase of compilation is a new pass where much of the historical code in `translate.rs` has been moved to (but heavily refactored). The goal of compilation is to produce one "flat" list of initializers for a component (as happens prior to this PR) and to achieve this an "inliner" phase runs which runs through the instantiation process at compile time to produce a list of initializers. This `inline` module is the main addition as part of this PR and is now the workhorse for dataflow analysis and tracking what's actually referring to what. During the `inline` phase the local initializers recorded in the `translate` phase are processed, in sequence, to instantiate a component. Definitions of items are tracked to correspond to their root definition which allows seeing across instantiation argument boundaries and such. Handling "upvars" for component outer aliases is handled in the `inline` phase as well by creating state for a component whenever a component is defined as was recorded during the `translate` phase. Finally this phase is chiefly responsible for doing all string-based name resolution at compile time that it can. This means that at runtime no string maps will need to be consulted for item exports and such. The final result of inlining is a list of "global initializers" which is a flat list processed during instantiation time. These are almost identical to the initializers that were processed prior to this PR. There are certainly still more gaps of the component model to implement but this should be a major leg up in terms of functionality that Wasmtime implements. This commit, however leaves behind a "hole" which is not intended to be filled in at this time, namely importing and exporting components at the "root" level from and to the host. This is tracked and explained in more detail as part of #4283. cc #4185 as this completes a number of items there * Tweak code to work on stable without warning * Review comments
2 years ago
(assert_invalid
(component
Update the wasm-tools family of crates (#5310) Most of the changes here are the updates to the component model which includes optional URL fields in imports/exports.
2 years ago
(import "a" (component))
Add support for nested components (#4285) * Add support for nested components This commit is an implementation of a number of features of the component model including: * Defining nested components * Outer aliases to components and modules * Instantiating nested components The implementation here is intended to be a foundational pillar of Wasmtime's component model support since recursion and nested components are the bread-and-butter of the component model. At a high level the intention for the component model implementation in Wasmtime has long been that the recursive nature of components is "erased" at compile time to something that's more optimized and efficient to process. This commit ended up exemplifying this quite well where the vast majority of the internal changes here are in the "compilation" phase of a component rather than the runtime instantiation phase. The support in the `wasmtime` crate, the runtime instantiation support, only had minor updates here while the internals of translation have seen heavy updates. The `translate` module was greatly refactored here in this commit. Previously it would, as a component is parsed, create a final `Component` to hand off to trampoline compilation and get persisted at runtime. Instead now it's a thin layer over `wasmparser` which simply records a list of `LocalInitializer` entries for how to instantiate the component and its index spaces are built. This internal representation of the instantiation of a component is pretty close to the binary format intentionally. Instead of performing dataflow legwork the `translate` phase of a component is now responsible for two primary tasks: 1. All components and modules are discovered within a component. They're assigned `Static{Component,Module}Index` depending on where they're found and a `{Module,}Translation` is prepared for each one. This "flattens" the recursive structure of the binary into an indexed list processable later. 2. The lexical scope of components is managed here to implement outer module and component aliases. This is a significant design implementation because when closing over an outer component or module that item may actually be imported or something like the result of a previous instantiation. This means that the capture of modules and components is both a lexical concern as well as a runtime concern. The handling of the "runtime" bits are handled in the next phase of compilation. The next and currently final phase of compilation is a new pass where much of the historical code in `translate.rs` has been moved to (but heavily refactored). The goal of compilation is to produce one "flat" list of initializers for a component (as happens prior to this PR) and to achieve this an "inliner" phase runs which runs through the instantiation process at compile time to produce a list of initializers. This `inline` module is the main addition as part of this PR and is now the workhorse for dataflow analysis and tracking what's actually referring to what. During the `inline` phase the local initializers recorded in the `translate` phase are processed, in sequence, to instantiate a component. Definitions of items are tracked to correspond to their root definition which allows seeing across instantiation argument boundaries and such. Handling "upvars" for component outer aliases is handled in the `inline` phase as well by creating state for a component whenever a component is defined as was recorded during the `translate` phase. Finally this phase is chiefly responsible for doing all string-based name resolution at compile time that it can. This means that at runtime no string maps will need to be consulted for item exports and such. The final result of inlining is a list of "global initializers" which is a flat list processed during instantiation time. These are almost identical to the initializers that were processed prior to this PR. There are certainly still more gaps of the component model to implement but this should be a major leg up in terms of functionality that Wasmtime implements. This commit, however leaves behind a "hole" which is not intended to be filled in at this time, namely importing and exporting components at the "root" level from and to the host. This is tracked and explained in more detail as part of #4283. cc #4185 as this completes a number of items there * Tweak code to work on stable without warning * Review comments
2 years ago
)
"root-level component imports are not supported")
(assert_invalid
(component
Update the wasm-tools family of crates (#5310) Most of the changes here are the updates to the component model which includes optional URL fields in imports/exports.
2 years ago
(component (export "a"))
Add support for nested components (#4285) * Add support for nested components This commit is an implementation of a number of features of the component model including: * Defining nested components * Outer aliases to components and modules * Instantiating nested components The implementation here is intended to be a foundational pillar of Wasmtime's component model support since recursion and nested components are the bread-and-butter of the component model. At a high level the intention for the component model implementation in Wasmtime has long been that the recursive nature of components is "erased" at compile time to something that's more optimized and efficient to process. This commit ended up exemplifying this quite well where the vast majority of the internal changes here are in the "compilation" phase of a component rather than the runtime instantiation phase. The support in the `wasmtime` crate, the runtime instantiation support, only had minor updates here while the internals of translation have seen heavy updates. The `translate` module was greatly refactored here in this commit. Previously it would, as a component is parsed, create a final `Component` to hand off to trampoline compilation and get persisted at runtime. Instead now it's a thin layer over `wasmparser` which simply records a list of `LocalInitializer` entries for how to instantiate the component and its index spaces are built. This internal representation of the instantiation of a component is pretty close to the binary format intentionally. Instead of performing dataflow legwork the `translate` phase of a component is now responsible for two primary tasks: 1. All components and modules are discovered within a component. They're assigned `Static{Component,Module}Index` depending on where they're found and a `{Module,}Translation` is prepared for each one. This "flattens" the recursive structure of the binary into an indexed list processable later. 2. The lexical scope of components is managed here to implement outer module and component aliases. This is a significant design implementation because when closing over an outer component or module that item may actually be imported or something like the result of a previous instantiation. This means that the capture of modules and components is both a lexical concern as well as a runtime concern. The handling of the "runtime" bits are handled in the next phase of compilation. The next and currently final phase of compilation is a new pass where much of the historical code in `translate.rs` has been moved to (but heavily refactored). The goal of compilation is to produce one "flat" list of initializers for a component (as happens prior to this PR) and to achieve this an "inliner" phase runs which runs through the instantiation process at compile time to produce a list of initializers. This `inline` module is the main addition as part of this PR and is now the workhorse for dataflow analysis and tracking what's actually referring to what. During the `inline` phase the local initializers recorded in the `translate` phase are processed, in sequence, to instantiate a component. Definitions of items are tracked to correspond to their root definition which allows seeing across instantiation argument boundaries and such. Handling "upvars" for component outer aliases is handled in the `inline` phase as well by creating state for a component whenever a component is defined as was recorded during the `translate` phase. Finally this phase is chiefly responsible for doing all string-based name resolution at compile time that it can. This means that at runtime no string maps will need to be consulted for item exports and such. The final result of inlining is a list of "global initializers" which is a flat list processed during instantiation time. These are almost identical to the initializers that were processed prior to this PR. There are certainly still more gaps of the component model to implement but this should be a major leg up in terms of functionality that Wasmtime implements. This commit, however leaves behind a "hole" which is not intended to be filled in at this time, namely importing and exporting components at the "root" level from and to the host. This is tracked and explained in more detail as part of #4283. cc #4185 as this completes a number of items there * Tweak code to work on stable without warning * Review comments
2 years ago
)
"exporting a component from the root component is not supported")
Add `*.wast` support for invoking components (#4526) This commit builds on bytecodealliance/wasm-tools#690 to add support to testing of the component model to execute functions when running `*.wast` files. This support is all built on #4442 as functions are invoked through a "dynamic" API. Right now the testing and integration is fairly crude but I'm hoping that we can try to improve it over time as necessary. For now this should provide a hopefully more convenient syntax for unit tests and the like.
2 years ago
(component
(core module $m (func (export "")))
(core instance $m (instantiate $m))
Update the wasm-tools family of crates (#5310) Most of the changes here are the updates to the component model which includes optional URL fields in imports/exports.
2 years ago
(func (export "a") (canon lift (core func $m "")))
Add `*.wast` support for invoking components (#4526) This commit builds on bytecodealliance/wasm-tools#690 to add support to testing of the component model to execute functions when running `*.wast` files. This support is all built on #4442 as functions are invoked through a "dynamic" API. Right now the testing and integration is fairly crude but I'm hoping that we can try to improve it over time as necessary. For now this should provide a hopefully more convenient syntax for unit tests and the like.
2 years ago
)
Update the wasm-tools family of crates (#5310) Most of the changes here are the updates to the component model which includes optional URL fields in imports/exports.
2 years ago
(assert_return (invoke "a"))