Skip to content

rustbuild: Enable WebAssembly backend by default - #46115

Merged
bors merged 1 commit into
rust-lang:masterfrom
alexcrichton:add-wasm-target
Nov 25, 2017
Merged

rustbuild: Enable WebAssembly backend by default#46115
bors merged 1 commit into
rust-lang:masterfrom
alexcrichton:add-wasm-target

Conversation

@alexcrichton

@alexcrichtonalexcrichton commented Nov 20, 2017

Copy link
Copy Markdown
Member

This commit alters how we compile LLVM by default enabling the WebAssembly
backend. This then also adds the wasm32-unknown-unknown target to get compiled
on the cross builder and distributed through rustup. Tests are not yet enabled
for this target but that should hopefully be coming soon!

@alexcrichton

alexcrichton commented Nov 20, 2017

Copy link
Copy Markdown
MemberAuthor

This is the successor of #45905 where now that everything's in tree it's time to add some tests! This PR will ensure that the wasm32-unknown-unknown target does not regress (keeps building) and also enables all of our distributed compilers to build for wasm32 architectures by default. This PR also adds a rustup target, so after this lands it will be possible to do:

rustup target add wasm32-unknown-unknown

and then you're ready to experiment! After this PR I'll work on adding a builder that starts running some tests so we can get some regression testing there.

@alexcrichton

alexcrichton commented Nov 20, 2017

Copy link
Copy Markdown
MemberAuthor

r? @kennytm

@alexcrichtonalexcrichton mentioned this pull request Nov 20, 2017
Merged
@kennytm

kennytm commented Nov 20, 2017

Copy link
Copy Markdown
Member

LGTM.

@bors r+

@bors

bors commented Nov 20, 2017

Copy link
Copy Markdown
Collaborator

📌 Commit 2e54755 has been approved by kennytm

@kennytmkennytm added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Nov 20, 2017
@est31

est31 commented Nov 20, 2017

Copy link
Copy Markdown
Member

Doesn't this need LLVM 5.0? Or was that requirement dropped?

@est31

est31 commented Nov 20, 2017

Copy link
Copy Markdown
Member

Hmm I guess it never was a hard requirement really, but there was just no testing on it...

@alexcrichton

alexcrichton commented Nov 20, 2017

Copy link
Copy Markdown
MemberAuthor

@bors: r-

turns out rustdoc for wasm is super broke, will fix.

@est31 yes for a bug-free implementation we'll probably need LLVM 5.0. I don't think there's any need to block on that-which-is-unlikely-to-ever-happen though

@alexcrichton

alexcrichton commented Nov 20, 2017

Copy link
Copy Markdown
MemberAuthor

re-r? @kennytm

The support added for documenting all platforms when documenting the standard library was broken with wasm b/c it didn't share enough in common to compile the unix/windows "tiny shims". I ended up using cfg_if! to clean up the declarations (cut down on #[cfg] traffic) and then had to fix the "everybody loops" implementation in rustc to get that working.

@kennytm

kennytm commented Nov 20, 2017

Copy link
Copy Markdown
Member

r=me after tidy fix.

[00:03:41] tidy error: /checkout/src/librustc_driver/lib.rs:568: line longer than 100 chars
[00:03:42] some tidy checks failed

@kennytmkennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 20, 2017
@alexcrichton

alexcrichton commented Nov 20, 2017

Copy link
Copy Markdown
MemberAuthor

@bors: r=kennytm

@bors

bors commented Nov 20, 2017

Copy link
Copy Markdown
Collaborator

📌 Commit dae3bb3 has been approved by kennytm

@kennytmkennytm added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Nov 21, 2017
@bors

bors commented Nov 25, 2017

Copy link
Copy Markdown
Collaborator

⌛ Testing commit dae3bb3de9602cf5d5cc8cfe61cd1059c33777dd with merge 4d6744e7de8a198b177f6f7b5d4c251cd6a730ad...

@bors

bors commented Nov 25, 2017

Copy link
Copy Markdown
Collaborator

💔 Test failed - status-travis

@kennytm

kennytm commented Nov 25, 2017•
edited
Loading

Copy link
Copy Markdown
Member

Cannot document libstd for x86_64-unknown-redox.

Details
[00:57:37] error[E0432]: unresolved import `sys::net::Socket`
[00:57:37] --> /checkout/src/libstd/sys/unix/ext/net.rs:39:5
[00:57:37] |
[00:57:37] 39 | use sys::net::Socket;
[00:57:37] | ^^^^^^^^^^^^^^^^ no `Socket` in `sys::redox::net`
[00:57:37] [00:57:38] error[E0119]: conflicting implementations of trait `sys::unix_ext::io::AsRawFd` for type `process::ChildStdin`:
[00:57:38] --> /checkout/src/libstd/sys/unix/ext/process.rs:154:1
[00:57:38] |
[00:57:38] 154 | / impl AsRawFd for process::ChildStdin {
[00:57:38] 155 | | fn as_raw_fd(&self) -> RawFd {
[00:57:38] 156 | | self.as_inner().fd().raw()
[00:57:38] 157 | | }
[00:57:38] 158 | | }
[00:57:38] | |_^ conflicting implementation for `process::ChildStdin`
[00:57:38] | [00:57:38] ::: /checkout/src/libstd/sys/redox/ext/process.rs
[00:57:38] |
[00:57:38] 144 | / impl AsRawFd for process::ChildStdin {
[00:57:38] 145 | | fn as_raw_fd(&self) -> RawFd {
[00:57:38] 146 | | self.as_inner().fd().raw()
[00:57:38] 147 | | }
[00:57:38] 148 | | }
[00:57:38] | |_- first implementation here
[00:57:38] [00:57:38] error[E0119]: conflicting implementations of trait `sys::unix_ext::io::AsRawFd` for type `process::ChildStdout`:
[00:57:38] --> /checkout/src/libstd/sys/unix/ext/process.rs:161:1
[00:57:38] |
[00:57:38] 161 | / impl AsRawFd for process::ChildStdout {
[00:57:38] 162 | | fn as_raw_fd(&self) -> RawFd {
[00:57:38] 163 | | self.as_inner().fd().raw()
[00:57:38] 164 | | }
[00:57:38] 165 | | }
[00:57:38] | |_^ conflicting implementation for `process::ChildStdout`
[00:57:38] | [00:57:38] ::: /checkout/src/libstd/sys/redox/ext/process.rs
[00:57:38] |
[00:57:38] 151 | / impl AsRawFd for process::ChildStdout {
[00:57:38] 152 | | fn as_raw_fd(&self) -> RawFd {
[00:57:38] 153 | | self.as_inner().fd().raw()
[00:57:38] 154 | | }
[00:57:38] 155 | | }
[00:57:38] | |_- first implementation here
[00:57:38] [00:57:38] error[E0119]: conflicting implementations of trait `sys::unix_ext::io::AsRawFd` for type `process::ChildStderr`:
[00:57:38] --> /checkout/src/libstd/sys/unix/ext/process.rs:168:1
[00:57:38] |
[00:57:38] 168 | / impl AsRawFd for process::ChildStderr {
[00:57:38] 169 | | fn as_raw_fd(&self) -> RawFd {
[00:57:38] 170 | | self.as_inner().fd().raw()
[00:57:38] 171 | | }
[00:57:38] 172 | | }
[00:57:38] | |_^ conflicting implementation for `process::ChildStderr`
[00:57:38] | [00:57:38] ::: /checkout/src/libstd/sys/redox/ext/process.rs
[00:57:38] |
[00:57:38] 158 | / impl AsRawFd for process::ChildStderr {
[00:57:38] 159 | | fn as_raw_fd(&self) -> RawFd {
[00:57:38] 160 | | self.as_inner().fd().raw()
[00:57:38] 161 | | }
[00:57:38] 162 | | }
[00:57:38] | |_- first implementation here
[00:57:38] [00:57:38] error[E0119]: conflicting implementations of trait `sys::unix_ext::io::FromRawFd` for type `process::Stdio`:
[00:57:38] --> /checkout/src/libstd/sys/unix/ext/process.rs:145:1
[00:57:38] |
[00:57:38] 145 | / impl FromRawFd for process::Stdio {
[00:57:38] 146 | | unsafe fn from_raw_fd(fd: RawFd) -> process::Stdio {
[00:57:38] 147 | | let fd = sys::fd::FileDesc::new(fd);
[00:57:38] 148 | | let io = sys::process::Stdio::Fd(fd);
[00:57:38] 149 | | process::Stdio::from_inner(io)
[00:57:38] 150 | | }
[00:57:38] 151 | | }
[00:57:38] | |_^ conflicting implementation for `process::Stdio`
[00:57:38] | [00:57:38] ::: /checkout/src/libstd/sys/redox/ext/process.rs
[00:57:38] |
[00:57:38] 135 | / impl FromRawFd for process::Stdio {
[00:57:38] 136 | | unsafe fn from_raw_fd(fd: RawFd) -> process::Stdio {
[00:57:38] 137 | | let fd = sys::fd::FileDesc::new(fd);
[00:57:38] 138 | | let io = sys::process::Stdio::Fd(fd);
[00:57:38] 139 | | process::Stdio::from_inner(io)
[00:57:38] 140 | | }
[00:57:38] 141 | | }
[00:57:38] | |_- first implementation here
[00:57:38] [00:57:38] error[E0119]: conflicting implementations of trait `sys::unix_ext::io::IntoRawFd` for type `process::ChildStdin`:
[00:57:38] --> /checkout/src/libstd/sys/unix/ext/process.rs:175:1
[00:57:38] |
[00:57:38] 175 | / impl IntoRawFd for process::ChildStdin {
[00:57:38] 176 | | fn into_raw_fd(self) -> RawFd {
[00:57:38] 177 | | self.into_inner().into_fd().into_raw()
[00:57:38] 178 | | }
[00:57:38] 179 | | }
[00:57:38] | |_^ conflicting implementation for `process::ChildStdin`
[00:57:38] | [00:57:38] ::: /checkout/src/libstd/sys/redox/ext/process.rs
[00:57:38] |
[00:57:38] 165 | / impl IntoRawFd for process::ChildStdin {
[00:57:38] 166 | | fn into_raw_fd(self) -> RawFd {
[00:57:38] 167 | | self.into_inner().into_fd().into_raw()
[00:57:38] 168 | | }
[00:57:38] 169 | | }
[00:57:38] | |_- first implementation here
[00:57:38] [00:57:38] error[E0119]: conflicting implementations of trait `sys::unix_ext::io::IntoRawFd` for type `process::ChildStdout`:
[00:57:38] --> /checkout/src/libstd/sys/unix/ext/process.rs:182:1
[00:57:38] |
[00:57:38] 182 | / impl IntoRawFd for process::ChildStdout {
[00:57:38] 183 | | fn into_raw_fd(self) -> RawFd {
[00:57:38] 184 | | self.into_inner().into_fd().into_raw()
[00:57:38] 185 | | }
[00:57:38] 186 | | }
[00:57:38] | |_^ conflicting implementation for `process::ChildStdout`
[00:57:38] | [00:57:38] ::: /checkout/src/libstd/sys/redox/ext/process.rs
[00:57:38] |
[00:57:38] 172 | / impl IntoRawFd for process::ChildStdout {
[00:57:38] 173 | | fn into_raw_fd(self) -> RawFd {
[00:57:38] 174 | | self.into_inner().into_fd().into_raw()
[00:57:38] 175 | | }
[00:57:38] 176 | | }
[00:57:38] | |_- first implementation here
[00:57:38] [00:57:38] error[E0119]: conflicting implementations of trait `sys::unix_ext::io::IntoRawFd` for type `process::ChildStderr`:
[00:57:38] --> /checkout/src/libstd/sys/unix/ext/process.rs:189:1
[00:57:38] |
[00:57:38] 189 | / impl IntoRawFd for process::ChildStderr {
[00:57:38] 190 | | fn into_raw_fd(self) -> RawFd {
[00:57:38] 191 | | self.into_inner().into_fd().into_raw()
[00:57:38] 192 | | }
[00:57:38] 193 | | }
[00:57:38] | |_^ conflicting implementation for `process::ChildStderr`
[00:57:38] | [00:57:38] ::: /checkout/src/libstd/sys/redox/ext/process.rs
[00:57:38] |
[00:57:38] 179 | / impl IntoRawFd for process::ChildStderr {
[00:57:38] 180 | | fn into_raw_fd(self) -> RawFd {
[00:57:38] 181 | | self.into_inner().into_fd().into_raw()
[00:57:38] 182 | | }
[00:57:38] 183 | | }
[00:57:38] | |_- first implementation here
[00:57:38] [00:57:38] error: Compilation failed, aborting rustdoc
[00:57:38] [00:57:38] �[m�[m�[31m�[1merror:�[m Could not document `std`.

@kennytmkennytm added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Nov 25, 2017
kennytm
kennytm reviewed Nov 25, 2017
View reviewed changes
Comment threadsrc/libstd/sys/mod.rs Outdated

@kennytmkennytmNov 25, 2017•
edited
Loading

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be #[cfg(any(unix, target_os = "redox"))] I guess.

But it also needs #[cfg(target_os = "redox")] use os::linux as platform;.

@alexcrichton
rustbuild: Enable WebAssembly backend by default
48996f9
This commit alters how we compile LLVM by default enabling the WebAssembly
backend. This then also adds the wasm32-unknown-unknown target to get compiled
on the `cross` builder and distributed through rustup. Tests are not yet enabled
for this target but that should hopefully be coming soon!
@alexcrichton

alexcrichton commented Nov 25, 2017

Copy link
Copy Markdown
MemberAuthor

@bors: r=kennytm

@bors

bors commented Nov 25, 2017

Copy link
Copy Markdown
Collaborator

📌 Commit 48996f9 has been approved by kennytm

@bors

bors commented Nov 25, 2017

Copy link
Copy Markdown
Collaborator

⌛ Testing commit 48996f9 with merge e97ba83...

bors added a commit that referenced this pull request Nov 25, 2017
@bors
Auto merge of#46115- alexcrichton:add-wasm-target, r=kennytm
e97ba83
rustbuild: Enable WebAssembly backend by default
This commit alters how we compile LLVM by default enabling the WebAssembly
backend. This then also adds the wasm32-unknown-unknown target to get compiled
on the `cross` builder and distributed through rustup. Tests are not yet enabled
for this target but that should hopefully be coming soon!
@bors

bors commented Nov 25, 2017

Copy link
Copy Markdown
Collaborator

☀️ Test successful - status-appveyor, status-travis
Approved by: kennytm
Pushing e97ba83 to master...

@bors
bors merged commit 48996f9 into rust-lang:masterNov 25, 2017
@alexcrichton
alexcrichton deleted the add-wasm-target branch November 25, 2017 21:35
@kennytmkennytm mentioned this pull request Nov 26, 2017
Closed
@huangjj27

huangjj27 commented Nov 28, 2017•
edited
Loading

Copy link
Copy Markdown

I found that function with return type String, Vec<i32> or &'static str can't be recognized by the front end, the function called return undefined. Is it some part of unfinshed work that cause this issue? sample code and output:

wasmInstance instantiated in line 11 // index.html:11:13
function sayHello instantiated in line 17 // index.html:17:13
undefined // index.html:18:13

front-end caller

letwasmInstance="";letaddRust="";fetchAndInstantiate('small-add.wasm',{}).then(instance=>{wasmInstance=instance;console.log("wasmInstance instantiated in line 11");sayHello=wasmInstance.exports.say_hello;console.log("function sayHello instantiated in line 17");console.log(sayHello());});

back-end callee:

#[no_mangle]pubfnsay_hello() -> &'staticstr{"hello, world! hello, rust wasm!"}

@badboy

badboy commented Nov 28, 2017

Copy link
Copy Markdown
Member

@huangjj27 That's on purpose and is simply the way Rust works. Strings, Vec, slices, etc. are returned by writing a pointer and additional data to a caller-allocated memory buffer, from which the caller has to read it after calling the function. Wasm has no idea about the layout of Strings. @killercup and I are working on a bit of JS boilerplate to handle those cases easily in wasm-experiments

@kennytm

kennytm commented Nov 28, 2017

Copy link
Copy Markdown
Member

@huangjj27 See also https://stackoverflow.com/questions/47529643/how-to-return-a-string-or-similar-from-rust-in-webassembly

alexcrichton added a commit to alexcrichton/rust that referenced this pull request Nov 30, 2017
@alexcrichton
rustc: Filter out bogus extern crate warnings
4e74eb5
Rustdoc has for some time now used the "everybody loops" pass in the compiler to
avoid typechecking and otherwise avoid looking at implementation details.
In rust-lang#46115 the placement of this pass was pushed back in the compiler to after
macro expansion to ensure that it works with macro-expanded code as well. This
in turn caused the regression in rust-lang#46271.
The bug here was that the resolver was producing `def_id` instances for
"possibly unused extern crates" which would then later get processed during
typeck to actually issue lint warnings. The problem was that *after* resolution
these `def_id` nodes were actually removed from the AST by the "everybody loops"
pass. This later, when we tried to take a look at `def_id`, caused the compiler
to panic.
The fix applied here is a bit of a heavy hammer which is to just, in this one
case, ignore the `extern crate` lints if the `def_id` looks "bogus" in any way
(basically if it looks like the node was removed after resolution). The real
underlying bug here is probably that the "everybody loops" AST pass is being
stressed to much beyond what it was originally intended to do, but this should
at least fix the ICE for now...
Closesrust-lang#46271
@alexcrichtonalexcrichton mentioned this pull request Nov 30, 2017
Merged
kennytm added a commit to kennytm/rust that referenced this pull request Dec 1, 2017
@kennytm
Rollup merge ofrust-lang#46405- alexcrichton:fix-rustdoc, r=estebank
3f99b7c
rustc: Filter out bogus extern crate warnings
Rustdoc has for some time now used the "everybody loops" pass in the compiler to
avoid typechecking and otherwise avoid looking at implementation details.
In rust-lang#46115 the placement of this pass was pushed back in the compiler to after
macro expansion to ensure that it works with macro-expanded code as well. This
in turn caused the regression in rust-lang#46271.
The bug here was that the resolver was producing `def_id` instances for
"possibly unused extern crates" which would then later get processed during
typeck to actually issue lint warnings. The problem was that *after* resolution
these `def_id` nodes were actually removed from the AST by the "everybody loops"
pass. This later, when we tried to take a look at `def_id`, caused the compiler
to panic.
The fix applied here is a bit of a heavy hammer which is to just, in this one
case, ignore the `extern crate` lints if the `def_id` looks "bogus" in any way
(basically if it looks like the node was removed after resolution). The real
underlying bug here is probably that the "everybody loops" AST pass is being
stressed to much beyond what it was originally intended to do, but this should
at least fix the ICE for now...
Closesrust-lang#46271
@bennyyipbennyyip mentioned this pull request Dec 2, 2017
Merged
@kennytmkennytm mentioned this pull request Feb 1, 2018
Closed
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@kennytmkennytmkennytm left review comments

Assignees

@kennytmkennytm

Labels

S-waiting-on-authorStatus: This is awaiting some action (such as code changes or more information) from the author.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

6 participants

@alexcrichton@kennytm@bors@est31@huangjj27@badboy