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

Fix compiling some rustc crates to wasm #54024

Merged
merged 1 commit into from
Sep 14, 2018

Conversation

alexcrichton
Copy link
Member

I was dabbling recently seeing what it would take to compile rustfmt to the
wasm32-unknown-unknown target and it turns out not much effort is needed!
Currently rustfmt depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:

  • The rustc_data_structures crate's flock implementation is stubbed out to
    unconditionally return errors on unsupported platforms.
  • The rustc_errors crate is extended to not do any locking for all non-windows
    platforms.

In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!

@rust-highfive
Copy link
Collaborator

r? @petrochenkov

(rust_highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 7, 2018
@alexcrichton
Copy link
Member Author

The diff here is best viewed ignoring whitespace

@rust-highfive
Copy link
Collaborator

The job x86_64-gnu-llvm-5.0 of your PR failed on Travis (raw log). Through arcane magic we have determined that the following fragments from the build log may contain information about the problem.

Click to expand the log.
[00:06:04]    Compiling backtrace v0.3.9
[00:06:05]    Compiling crossbeam-deque v0.2.0
[00:06:08]    Compiling rustc-rayon v0.1.1
[00:06:14]    Compiling rustc_data_structures v0.0.0 (file:///checkout/src/librustc_data_structures)
[00:06:14] error[E0252]: the name `Path` is defined multiple times
[00:06:14]   --> librustc_data_structures/flock.rs:27:13
[00:06:14] 21 | use std::path::Path;
[00:06:14] 21 | use std::path::Path;
[00:06:14]    |     --------------- previous import of the type `Path` here
[00:06:14] 27 |         use std::path::Path;
[00:06:14] 27 |         use std::path::Path;
[00:06:14]    |             ^^^^^^^^^^^^^^^ `Path` reimported here
[00:06:14]    |
[00:06:14]    = note: `Path` must be defined only once in the type namespace of this module
[00:06:14] help: You can use `as` to change the binding name of the import
[00:06:14] 27 |         use std::path::Path as OtherPath;
[00:06:14]    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[00:06:14] 
[00:06:14] error: unused import: `std::path::Path`
---
[00:06:16] For more information about this error, try `rustc --explain E0252`.
[00:06:16] error: Could not compile `rustc_data_structures`.
[00:06:16] 
[00:06:16] Caused by:
[00:06:16]   process didn't exit successfully: `/checkout/obj/build/bootstrap/debug/rustc --crate-name rustc_data_structures librustc_data_structures/lib.rs --color always --error-format json --crate-type dylib --emit=dep-info,link -C prefer-dynamic -C opt-level=2 -C metadata=05301c67193a930e -C extra-filename=-05301c67193a930e --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps --target x86_64-unknown-linux-gnu -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps -L dependency=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/release/deps --extern cfg_if=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libcfg_if-c76d7635015dbd91.rlib --extern ena=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libena-78f18b1831cf7d50.rlib --extern log=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/liblog-c55d6c95192e4906.rlib --extern parking_lot=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libparking_lot-87308d43fa547c79.rlib --extern parking_lot_core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libparking_lot_core-f33344b1613f3387.rlib --extern rustc_hash=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_hash-b1d18f68284bbb3d.rlib --extern rustc_rayon=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_rayon-f58fc2695e5bd48d.rlib --extern rustc_rayon_core=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_rayon_core-4928a7a7d96a17f8.rlib --extern rustc_cratesio_shim=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/librustc_cratesio_shim-b3ce1c0970d50596.so --extern serialize=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libserialize-8d84add221c0f710.so --extern serialize=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libserialize-8d84add221c0f710.rlib --extern smallvec=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libsmallvec-cb741677cd0e0351.rlib --extern stable_deref_trait=/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-rustc/x86_64-unknown-linux-gnu/release/deps/libstable_deref_trait-712b2a476a36a5ef.rlib` (exit code: 1)

I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact @TimNN. (Feature Requests)

I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:

* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
  unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
  platforms.

In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!
@petrochenkov
Copy link
Contributor

@bors r+

@bors
Copy link
Contributor

bors commented Sep 8, 2018

📌 Commit 0c89243 has been approved by petrochenkov

@bors bors 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-review Status: Awaiting review from the assignee but also interested parties. labels Sep 8, 2018
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this pull request Sep 8, 2018
…rochenkov

Fix compiling some rustc crates to wasm

I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:

* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
  unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
  platforms.

In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!
kennytm added a commit to kennytm/rust that referenced this pull request Sep 14, 2018
…rochenkov

Fix compiling some rustc crates to wasm

I was dabbling recently seeing what it would take to compile `rustfmt` to the
`wasm32-unknown-unknown` target and it turns out not much effort is needed!
Currently `rustfmt` depends on a few rustc crates published to crates.io, so
this commit touches up those crates to compile for wasm themselves. Notably:

* The `rustc_data_structures` crate's `flock` implementation is stubbed out to
  unconditionally return errors on unsupported platforms.
* The `rustc_errors` crate is extended to not do any locking for all non-windows
  platforms.

In both of these cases if we port the compiler to new platforms the
functionality isn't critical but will be discovered over time as it comes up, so
this hopefully doesn't make it too too hard to compile to new platforms!
bors added a commit that referenced this pull request Sep 14, 2018
Rollup of 8 pull requests

Successful merges:

 - #53218 (Add a implementation of `From` for converting `&'a Option<T>` into `Option<&'a T>`)
 - #54024 (Fix compiling some rustc crates to wasm)
 - #54095 (Rename all mentions of `nil` to `unit`)
 - #54173 (Suggest valid crate type if invalid crate type is found)
 - #54194 (Remove println!() statement from HashMap unit test)
 - #54203 (Fix the stable release of os_str_str_ref_eq)
 - #54207 (re-mark the never docs as unstable)
 - #54210 (Update Cargo)

Failed merges:

r? @ghost
@bors
Copy link
Contributor

bors commented Sep 14, 2018

⌛ Testing commit 0c89243 with merge fccde00...

@bors bors merged commit 0c89243 into rust-lang:master Sep 14, 2018
@alexcrichton alexcrichton deleted the compile-to-wasm branch October 8, 2018 19:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants