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

@alexcrichton alexcrichton commented Nov 20, 2017

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

@alexcrichton alexcrichton commented Nov 20, 2017

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

@alexcrichton alexcrichton commented Nov 20, 2017

@kennytm
Copy link
Member

@kennytm kennytm commented Nov 20, 2017

LGTM.

@bors r+

@bors
Copy link
Contributor

@bors bors commented Nov 20, 2017

📌 Commit 2e54755 has been approved by kennytm

@est31
Copy link
Contributor

@est31 est31 commented Nov 20, 2017

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

@est31
Copy link
Contributor

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

@alexcrichton alexcrichton commented Nov 20, 2017

@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 force-pushed the alexcrichton:add-wasm-target branch from 2e54755 to 969c9ac Nov 20, 2017
@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Nov 20, 2017

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 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
@alexcrichton alexcrichton force-pushed the alexcrichton:add-wasm-target branch from 969c9ac to dae3bb3 Nov 20, 2017
@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Nov 20, 2017

@bors: r=kennytm

@bors
Copy link
Contributor

@bors bors commented Nov 20, 2017

📌 Commit dae3bb3 has been approved by kennytm

@bors
Copy link
Contributor

@bors bors commented Nov 25, 2017

Testing commit dae3bb3 with merge 4d6744e...

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 bors commented Nov 25, 2017

💔 Test failed - status-travis

@kennytm
Copy link
Member

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

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

This comment has been minimized.

@kennytm

kennytm Nov 25, 2017
Member

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 alexcrichton force-pushed the alexcrichton:add-wasm-target branch from dae3bb3 to 48996f9 Nov 25, 2017
@alexcrichton
Copy link
Member Author

@alexcrichton alexcrichton commented Nov 25, 2017

@bors: r=kennytm

@bors
Copy link
Contributor

@bors bors commented Nov 25, 2017

📌 Commit 48996f9 has been approved by kennytm

@bors
Copy link
Contributor

@bors 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 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
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
homu Test successful
Details
@alexcrichton alexcrichton deleted the alexcrichton:add-wasm-target branch Nov 25, 2017
@huangjj27
Copy link

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

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
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

6 participants
You can’t perform that action at this time.