rust-lang/rust
1
0
Fork 0
Code Issues Pull Requests Actions 1 Packages Projects Releases Wiki Activity
Files
359bfa901b9d8eddbed7b88b6716dbb77b7bfb95
rust/tests/ui/wasm/wasm-import-module.stderr

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

97 lines
3.8 KiB
Plaintext
Raw Normal View History

Changes to the uitests Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-16 13:46:25 +02:00
error[E0539]: malformed `link` attribute input
--> $DIR/wasm-import-module.rs:3:1
rustc: Add a `#[wasm_import_module]` attribute This commit adds a new attribute to the Rust compiler specific to the wasm target (and no other targets). The `#[wasm_import_module]` attribute is used to specify the module that a name is imported from, and is used like so: #[wasm_import_module = "./foo.js"] extern { fn some_js_function(); } Here the import of the symbol `some_js_function` is tagged with the `./foo.js` module in the wasm output file. Wasm-the-format includes two fields on all imports, a module and a field. The field is the symbol name (`some_js_function` above) and the module has historically unconditionally been `"env"`. I'm not sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd like the ability to configure it! The proposed ES module integration with wasm (aka a wasm module is "just another ES module") requires that the import module of wasm imports is interpreted as an ES module import, meaning that you'll need to encode paths, NPM packages, etc. As a result, we'll need this to be something other than `"env"`! Unfortunately neither our version of LLVM nor LLD supports custom import modules (aka anything not `"env"`). My hope is that by the time LLVM 7 is released both will have support, but in the meantime this commit adds some primitive encoding/decoding of wasm files to the compiler. This way rustc postprocesses the wasm module that LLVM emits to ensure it's got all the imports we'd like to have in it. Eventually I'd ideally like to unconditionally require this attribute to be placed on all `extern { ... }` blocks. For now though it seemed prudent to add it as an unstable attribute, so for now it's not required (as that'd force usage of a feature gate). Hopefully it doesn't take too long to "stabilize" this! cc rust-lang-nursery/rust-wasm#29
2018-02-10 14:28:17 -08:00
|
Update tests
2019-03-09 15:03:44 +03:00
LL | #[link(name = "...", wasm_import_module)]
Changes to the uitests Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-16 13:46:25 +02:00
| ^^^^^^^^^^^^^^^^^^^^^------------------^^
| |
| expected this to be of the form `wasm_import_module = "..."`
|
= note: for more information, visit <https://doc.rust-lang.org/reference/items/external-blocks.html#the-link-attribute>
help: try changing it to one of the following valid forms of the attribute
|
LL - #[link(name = "...", wasm_import_module)]
LL + #[link(name = "...")]
|
LL - #[link(name = "...", wasm_import_module)]
LL + #[link(name = "...", import_name_type = "decorated|noprefix|undecorated")]
|
LL - #[link(name = "...", wasm_import_module)]
LL + #[link(name = "...", kind = "dylib|static|...")]
|
LL - #[link(name = "...", wasm_import_module)]
LL + #[link(name = "...", kind = "dylib|static|...", wasm_import_module = "...", import_name_type = "decorated|noprefix|undecorated")]
|
= and 1 other candidate
rustc: Add a `#[wasm_import_module]` attribute This commit adds a new attribute to the Rust compiler specific to the wasm target (and no other targets). The `#[wasm_import_module]` attribute is used to specify the module that a name is imported from, and is used like so: #[wasm_import_module = "./foo.js"] extern { fn some_js_function(); } Here the import of the symbol `some_js_function` is tagged with the `./foo.js` module in the wasm output file. Wasm-the-format includes two fields on all imports, a module and a field. The field is the symbol name (`some_js_function` above) and the module has historically unconditionally been `"env"`. I'm not sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd like the ability to configure it! The proposed ES module integration with wasm (aka a wasm module is "just another ES module") requires that the import module of wasm imports is interpreted as an ES module import, meaning that you'll need to encode paths, NPM packages, etc. As a result, we'll need this to be something other than `"env"`! Unfortunately neither our version of LLVM nor LLD supports custom import modules (aka anything not `"env"`). My hope is that by the time LLVM 7 is released both will have support, but in the meantime this commit adds some primitive encoding/decoding of wasm files to the compiler. This way rustc postprocesses the wasm module that LLVM emits to ensure it's got all the imports we'd like to have in it. Eventually I'd ideally like to unconditionally require this attribute to be placed on all `extern { ... }` blocks. For now though it seemed prudent to add it as an unstable attribute, so for now it's not required (as that'd force usage of a feature gate). Hopefully it doesn't take too long to "stabilize" this! cc rust-lang-nursery/rust-wasm#29
2018-02-10 14:28:17 -08:00
Changes to the uitests Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-16 13:46:25 +02:00
error[E0539]: malformed `link` attribute input
--> $DIR/wasm-import-module.rs:6:1
rustc: Add a `#[wasm_import_module]` attribute This commit adds a new attribute to the Rust compiler specific to the wasm target (and no other targets). The `#[wasm_import_module]` attribute is used to specify the module that a name is imported from, and is used like so: #[wasm_import_module = "./foo.js"] extern { fn some_js_function(); } Here the import of the symbol `some_js_function` is tagged with the `./foo.js` module in the wasm output file. Wasm-the-format includes two fields on all imports, a module and a field. The field is the symbol name (`some_js_function` above) and the module has historically unconditionally been `"env"`. I'm not sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd like the ability to configure it! The proposed ES module integration with wasm (aka a wasm module is "just another ES module") requires that the import module of wasm imports is interpreted as an ES module import, meaning that you'll need to encode paths, NPM packages, etc. As a result, we'll need this to be something other than `"env"`! Unfortunately neither our version of LLVM nor LLD supports custom import modules (aka anything not `"env"`). My hope is that by the time LLVM 7 is released both will have support, but in the meantime this commit adds some primitive encoding/decoding of wasm files to the compiler. This way rustc postprocesses the wasm module that LLVM emits to ensure it's got all the imports we'd like to have in it. Eventually I'd ideally like to unconditionally require this attribute to be placed on all `extern { ... }` blocks. For now though it seemed prudent to add it as an unstable attribute, so for now it's not required (as that'd force usage of a feature gate). Hopefully it doesn't take too long to "stabilize" this! cc rust-lang-nursery/rust-wasm#29
2018-02-10 14:28:17 -08:00
|
Update tests
2019-03-09 15:03:44 +03:00
LL | #[link(name = "...", wasm_import_module(x))]
Changes to the uitests Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-16 13:46:25 +02:00
| ^^^^^^^^^^^^^^^^^^^^^---------------------^^
| |
| expected this to be of the form `wasm_import_module = "..."`
|
= note: for more information, visit <https://doc.rust-lang.org/reference/items/external-blocks.html#the-link-attribute>
help: try changing it to one of the following valid forms of the attribute
|
LL - #[link(name = "...", wasm_import_module(x))]
LL + #[link(name = "...")]
|
LL - #[link(name = "...", wasm_import_module(x))]
LL + #[link(name = "...", import_name_type = "decorated|noprefix|undecorated")]
|
LL - #[link(name = "...", wasm_import_module(x))]
LL + #[link(name = "...", kind = "dylib|static|...")]
|
LL - #[link(name = "...", wasm_import_module(x))]
LL + #[link(name = "...", kind = "dylib|static|...", wasm_import_module = "...", import_name_type = "decorated|noprefix|undecorated")]
|
= and 1 other candidate
rustc: Add a `#[wasm_import_module]` attribute This commit adds a new attribute to the Rust compiler specific to the wasm target (and no other targets). The `#[wasm_import_module]` attribute is used to specify the module that a name is imported from, and is used like so: #[wasm_import_module = "./foo.js"] extern { fn some_js_function(); } Here the import of the symbol `some_js_function` is tagged with the `./foo.js` module in the wasm output file. Wasm-the-format includes two fields on all imports, a module and a field. The field is the symbol name (`some_js_function` above) and the module has historically unconditionally been `"env"`. I'm not sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd like the ability to configure it! The proposed ES module integration with wasm (aka a wasm module is "just another ES module") requires that the import module of wasm imports is interpreted as an ES module import, meaning that you'll need to encode paths, NPM packages, etc. As a result, we'll need this to be something other than `"env"`! Unfortunately neither our version of LLVM nor LLD supports custom import modules (aka anything not `"env"`). My hope is that by the time LLVM 7 is released both will have support, but in the meantime this commit adds some primitive encoding/decoding of wasm files to the compiler. This way rustc postprocesses the wasm module that LLVM emits to ensure it's got all the imports we'd like to have in it. Eventually I'd ideally like to unconditionally require this attribute to be placed on all `extern { ... }` blocks. For now though it seemed prudent to add it as an unstable attribute, so for now it's not required (as that'd force usage of a feature gate). Hopefully it doesn't take too long to "stabilize" this! cc rust-lang-nursery/rust-wasm#29
2018-02-10 14:28:17 -08:00
Changes to the uitests Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-16 13:46:25 +02:00
error[E0539]: malformed `link` attribute input
--> $DIR/wasm-import-module.rs:9:1
rustc: Stabilize #[wasm_import_module] as #[link(...)] This commit stabilizes the `#[wasm_import_module]` attribute as `#[link(wasm_import_module = "...")]`. Tracked by #52090 this new directive in the `#[link]` attribute is used to configured the module name that the imports are listed with. The WebAssembly specification indicates two utf-8 names are associated with all imported items, one for the module the item comes from and one for the item itself. The item itself is configurable in Rust via its identifier or `#[link_name = "..."]`, but the module name was previously not configurable and defaulted to `"env"`. This commit ensures that this is also configurable. Closes #52090
2018-07-16 11:31:14 -07:00
|
Update tests
2019-03-09 15:03:44 +03:00
LL | #[link(name = "...", wasm_import_module())]
Changes to the uitests Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-16 13:46:25 +02:00
| ^^^^^^^^^^^^^^^^^^^^^--------------------^^
| |
| expected this to be of the form `wasm_import_module = "..."`
|
= note: for more information, visit <https://doc.rust-lang.org/reference/items/external-blocks.html#the-link-attribute>
help: try changing it to one of the following valid forms of the attribute
|
LL - #[link(name = "...", wasm_import_module())]
LL + #[link(name = "...")]
|
LL - #[link(name = "...", wasm_import_module())]
LL + #[link(name = "...", import_name_type = "decorated|noprefix|undecorated")]
|
LL - #[link(name = "...", wasm_import_module())]
LL + #[link(name = "...", kind = "dylib|static|...")]
|
LL - #[link(name = "...", wasm_import_module())]
LL + #[link(name = "...", kind = "dylib|static|...", wasm_import_module = "...", import_name_type = "decorated|noprefix|undecorated")]
|
= and 1 other candidate
rustc: Stabilize #[wasm_import_module] as #[link(...)] This commit stabilizes the `#[wasm_import_module]` attribute as `#[link(wasm_import_module = "...")]`. Tracked by #52090 this new directive in the `#[link]` attribute is used to configured the module name that the imports are listed with. The WebAssembly specification indicates two utf-8 names are associated with all imported items, one for the module the item comes from and one for the item itself. The item itself is configurable in Rust via its identifier or `#[link_name = "..."]`, but the module name was previously not configurable and defaulted to `"env"`. This commit ensures that this is also configurable. Closes #52090
2018-07-16 11:31:14 -07:00
rustc: Stricter checking for #[link] attributes
2022-03-14 13:28:34 +03:00
error: `wasm_import_module` is incompatible with other arguments in `#[link]` attributes
--> $DIR/wasm-import-module.rs:12:8
|
LL | #[link(wasm_import_module = "foo", name = "bar")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
error: `wasm_import_module` is incompatible with other arguments in `#[link]` attributes
--> $DIR/wasm-import-module.rs:15:8
|
LL | #[link(wasm_import_module = "foo", kind = "dylib")]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
error: `wasm_import_module` is incompatible with other arguments in `#[link]` attributes
--> $DIR/wasm-import-module.rs:18:8
|
Use `cfg(false)` in UI tests
2025-03-29 17:24:03 +00:00
LL | #[link(wasm_import_module = "foo", cfg(false))]
rustc: Stricter checking for #[link] attributes
2022-03-14 13:28:34 +03:00
| ^^^^^^^^^^^^^^^^^^^^^^^^^^
error: aborting due to 6 previous errors
rustc: Add a `#[wasm_import_module]` attribute This commit adds a new attribute to the Rust compiler specific to the wasm target (and no other targets). The `#[wasm_import_module]` attribute is used to specify the module that a name is imported from, and is used like so: #[wasm_import_module = "./foo.js"] extern { fn some_js_function(); } Here the import of the symbol `some_js_function` is tagged with the `./foo.js` module in the wasm output file. Wasm-the-format includes two fields on all imports, a module and a field. The field is the symbol name (`some_js_function` above) and the module has historically unconditionally been `"env"`. I'm not sure if this `"env"` convention has asm.js or LLVM roots, but regardless we'd like the ability to configure it! The proposed ES module integration with wasm (aka a wasm module is "just another ES module") requires that the import module of wasm imports is interpreted as an ES module import, meaning that you'll need to encode paths, NPM packages, etc. As a result, we'll need this to be something other than `"env"`! Unfortunately neither our version of LLVM nor LLD supports custom import modules (aka anything not `"env"`). My hope is that by the time LLVM 7 is released both will have support, but in the meantime this commit adds some primitive encoding/decoding of wasm files to the compiler. This way rustc postprocesses the wasm module that LLVM emits to ensure it's got all the imports we'd like to have in it. Eventually I'd ideally like to unconditionally require this attribute to be placed on all `extern { ... }` blocks. For now though it seemed prudent to add it as an unstable attribute, so for now it's not required (as that'd force usage of a feature gate). Hopefully it doesn't take too long to "stabilize" this! cc rust-lang-nursery/rust-wasm#29
2018-02-10 14:28:17 -08:00
Changes to the uitests Signed-off-by: Jonathan Brouwer <jonathantbrouwer@gmail.com>
2025-07-16 13:46:25 +02:00
For more information about this error, try `rustc --explain E0539`.
Reference in New Issue Copy Permalink