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

rustbuild: Enable WebAssembly backend by default #46115

Merged
merged 1 commit into from
Nov 25, 2017

Conversation

alexcrichton
Copy link
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
Copy link
Member Author

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
Copy link
Member Author

r? @kennytm

@kennytm
Copy link
Member

kennytm commented Nov 20, 2017

LGTM.

@bors r+

@bors
Copy link
Contributor

bors commented Nov 20, 2017

📌 Commit 2e54755 has been approved by kennytm

@kennytm kennytm 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
Copy link
Member

est31 commented Nov 20, 2017

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

@est31
Copy link
Member

est31 commented Nov 20, 2017

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

@alexcrichton
Copy link
Member Author

@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
Copy link
Member Author

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
Copy link
Member

kennytm commented Nov 20, 2017

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

@kennytm kennytm 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
Copy link
Member Author

@bors: r=kennytm

@bors
Copy link
Contributor

bors commented Nov 20, 2017

📌 Commit dae3bb3 has been approved by kennytm

@kennytm kennytm 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
Copy link
Contributor

bors commented Nov 25, 2017

⌛ Testing commit dae3bb3de9602cf5d5cc8cfe61cd1059c33777dd with merge 4d6744e7de8a198b177f6f7b5d4c251cd6a730ad...

@bors
Copy link
Contributor

bors commented Nov 25, 2017

💔 Test failed - status-travis

@kennytm
Copy link
Member

kennytm commented Nov 25, 2017

Cannot document libstd for x86_64-unknown-redox.

[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`.

@kennytm kennytm 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

#[cfg(dox)]
cfg_if! {
if #[cfg(unix)] {
Copy link
Member

@kennytm kennytm Nov 25, 2017

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;.

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
Copy link
Member Author

@bors: r=kennytm

@bors
Copy link
Contributor

bors commented Nov 25, 2017

📌 Commit 48996f9 has been approved by kennytm

@bors
Copy link
Contributor

bors commented Nov 25, 2017

⌛ Testing commit 48996f9 with merge e97ba83...

bors added a commit that referenced this pull request Nov 25, 2017
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
Copy link
Contributor

bors commented Nov 25, 2017

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

@bors bors merged commit 48996f9 into rust-lang:master Nov 25, 2017
@alexcrichton alexcrichton deleted the add-wasm-target branch November 25, 2017 21:35
@huangjj27
Copy link

huangjj27 commented Nov 28, 2017

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

let wasmInstance = "";
let addRust = "";

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]
pub fn say_hello() -> &'static str {
	"hello, world! hello, rust wasm!"
}

@badboy
Copy link
Member

badboy commented Nov 28, 2017

@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
Copy link
Member

kennytm commented Nov 28, 2017

@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
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...

Closes rust-lang#46271
kennytm added a commit to kennytm/rust that referenced this pull request Dec 1, 2017
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...

Closes rust-lang#46271
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants