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

Rollup of 16 pull requests #48348

Closed
wants to merge 59 commits into from
Closed

Conversation

jseyfried and others added 30 commits February 8, 2018 16:27
This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.

Moving to LLD brings with it a number of benefits for wasm code:

* LLD is itself an actual linker, so there's no need to compile all wasm code
  with LTO any more. As a result builds should be *much* speedier as LTO is no
  longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
  This, I believe at least, is intended to be the main supported linker for
  native code and wasm moving forward. Picking up support early on should help
  ensure that we can help LLD identify bugs and otherwise prove that it works
  great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
  and LLD (from what I can tell at least), so it's in general much better to be
  on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
  will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
  means a postprocessor is no longer needed to show off Rust's "small wasm
  binary size".

LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!

LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.

Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.

Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.

[gc]: https://reviews.llvm.org/D42511
This commit refactors how the path to the linker that we're going to invoke is
selected. Previously all targets listed *both* a `LinkerFlavor` and a `linker`
(path) option, but this meant that whenever you changed one you had to change
the other. The purpose of this commit is to avoid coupling these where possible.

Target specifications now only unconditionally define the *flavor* of the linker
that they're using by default. If not otherwise specified each flavor now
implies a particular default linker to run. As a result, this means that if
you'd like to test out `ld` for example you should be able to do:

    rustc -Z linker-flavor=ld foo.rs

whereas previously you had to do

    rustc -Z linker-flavor=ld -C linker=ld foo.rs

This will hopefully make it a bit easier to tinker around with variants that
should otherwise be well known to work, for example with LLD, `ld` on OSX, etc.
The fallible version of for_each and the stateless version of try_fold.
Instead of creating inference variables for those argument types, use
the trait error-reporting code to give a nicer error.
We need two-phase borrows of ops to be in the initial NLL release since without
them lots of existing code will break. Fixes rust-lang#48129
…enums

This dates back to at least rust-lang#26583. At the time, usize and isize were considered ffi-unsafe to nudge people away from them, but this changed in the aforementioned PR, making it inconsistent to complain about it in enum discriminants. In fact, repr(usize) is probably the best way to interface with `enum Foo : size_t { ... }`.
- Always name the non-FFI-safe
- Explain *why* the type is not FFI-safe
- Stop vaguely gesturing at structs/enums/unions if the non-FFI-safe types occured in a field.

The last part is arguably a regression, but it's minor now that the non-FFI-safe type is actually named. Removing it avoids some code duplication.
The suggestion is unconditional, so following it could lead to further errors. This is already the case for the repr(C) suggestion, which makes this acceptable, though not *good*. Checking up-front whether the suggestion can help would be great but applies more broadly (and would require some refactoring to avoid duplicating the checks).
…objects

It's unhelpful since raw pointers to trait objects are also FFI-unsafe and casting to a thin raw pointer loses the vtable. There are working solutions that _involve_ raw pointers but they're too complex to explain in one line and have serious trade offs.
Closes rust-lang#47981

This is pretty unsatisfying since it is working around a span bug. However, I can't track down the span bug and it could be in the parser, proc macro expansion, the user macro, or Syn (or any other library that can manipulate spans). Given that user code can cause this error, I think we need to be more robust here.
…ene, r=jseyfried

macros: improve struct constructor field hygiene, fix span bug

Fixes rust-lang#47311.
r? @nrc
…d_access_hygiene, r=petrochenkov

Improve tuple struct field access hygiene

Fixes rust-lang#47312 by fixing a span bug.
r? @nrc
…atsakis

Error on nested impl Trait and path projections from impl Trait

cc rust-lang#34511

r? @nikomatsakis
… r=GuillaumeGomez

rustdoc: move manual "extern crate" statements outside automatic "fn main"s in doctests

Gated on rust-lang#48095 - I based the branch atop that so i could show off the change in one of its tests, the actual change in this PR is just the last commit

There are a handful of unfortunate assumptions in the way rustdoc processes `extern crate` statements in doctests:

1. In the absence of an `extern crate` statement in the test, if the test also uses the local crate name, it will automatically insert an `extern crate cratename;` statement into the test.
2. If the doctest *does* include an `extern crate` statement, rustdoc will not automatically insert one, on the assumption that doing so would introduce a duplicate import.
3. If a doctest does not have the substring `fn main` outside a comment, rustdoc will wrap the whole doctest in a generated `fn main` so it can be compiled.

In short, whenever you write a doctest like this...

```rust
//! extern crate my_crate;
//! my_crate::some_cool_thing();
```

...rustdoc will turn it into (something like) this:

```rust
fn main() {
extern crate my_crate;
my_crate::some_cool_thing();
}
```

This creates issues when compiled, because now `my_crate` isn't even properly in scope! This forces people who want to have multiple crates in their doctests (or an explicit `extern crate` statement) to also manually include their own `fn main`, so rustdoc doesn't put their imports in the wrong place.

This PR just taps into another processing step rustdoc does to doctests: Whenever you add an `#![inner_attribute]` to the beginning of a doctest, rustdoc will actually splice those out and put it before the generated `fn main`. Now, we can just do the same with `extern crate`s at the beginning, too, and get a much nicer experience.

Now, the above example will be converted into this:

```rust
extern crate my_crate;
fn main() {
my_crate::some_cool_thing();
}
```
…um-args, r=estebank

detect wrong number of args when type-checking a closure

Instead of creating inference variables for those argument types, use
the trait error-reporting code to give a nicer error. This also
improves some other spans for existing tests.

Fixes rust-lang#47244

r? @estebank
rust: Import LLD for linking wasm objects

This commit imports the LLD project from LLVM to serve as the default linker for
the `wasm32-unknown-unknown` target. The `binaryen` submoule is consequently
removed along with "binaryen linker" support in rustc.

Moving to LLD brings with it a number of benefits for wasm code:

* LLD is itself an actual linker, so there's no need to compile all wasm code
  with LTO any more. As a result builds should be *much* speedier as LTO is no
  longer forcibly enabled for all builds of the wasm target.
* LLD is quickly becoming an "official solution" for linking wasm code together.
  This, I believe at least, is intended to be the main supported linker for
  native code and wasm moving forward. Picking up support early on should help
  ensure that we can help LLD identify bugs and otherwise prove that it works
  great for all our use cases!
* Improvements to the wasm toolchain are currently primarily focused around LLVM
  and LLD (from what I can tell at least), so it's in general much better to be
  on this bandwagon for bugfixes and new features.
* Historical "hacks" like `wasm-gc` will soon no longer be necessary, LLD
  will [natively implement][gc] `--gc-sections` (better than `wasm-gc`!) which
  means a postprocessor is no longer needed to show off Rust's "small wasm
  binary size".

LLD is added in a pretty standard way to rustc right now. A new rustbuild target
was defined for building LLD, and this is executed when a compiler's sysroot is
being assembled. LLD is compiled against the LLVM that we've got in tree, which
means we're currently on the `release_60` branch, but this may get upgraded in
the near future!

LLD is placed into rustc's sysroot in a `bin` directory. This is similar to
where `gcc.exe` can be found on Windows. This directory is automatically added
to `PATH` whenever rustc executes the linker, allowing us to define a `WasmLd`
linker which implements the interface that `wasm-ld`, LLD's frontend, expects.

Like Emscripten the LLD target is currently only enabled for Tier 1 platforms,
notably OSX/Windows/Linux, and will need to be installed manually for compiling
to wasm on other platforms. LLD is by default turned off in rustbuild, and
requires a `config.toml` option to be enabled to turn it on.

Finally the unstable `#![wasm_import_memory]` attribute was also removed as LLD
has a native option for controlling this.

[gc]: https://reviews.llvm.org/D42511
Add Iterator::try_for_each

The fallible version of `for_each` aka the stateless version of `try_fold`.  Inspired by @cuviper's comment in rust-lang#45379 (comment) as a more direct and obvious solution than `.map(f).collect::<Result<(), _>>()`.

Like `for_each`, no need for an `r` version thanks to overrides in `Rev`.

`iterator_try_fold` tracking issue: rust-lang#45594
…coding, r=nikomatsakis

incr.comp.: Don't keep RefCells in on-disk-cache borrowed in order to allow for recursive invocations.

Fixes rust-lang#47972.

r? @nikomatsakis
…, r=nikomatsakis

Allow two-phase borrows of &mut self in ops

We need two-phase borrows of ops to be in the initial NLL release since without them lots of existing code will break. Fixes rust-lang#48129.
CC @pnkfelix  and @nikomatsakis

r? @pnkfelix
…tebank

inform user where to give a type annotation

should resolve rust-lang#47777
previous pull request rust-lang#47982 was closed because of a mistaken rebase.
r? @estebank
…komatsakis

incr.comp.: Store DepNode colors in a dense array instead of a hashmap.

Implements half of rust-lang#47293.

r? @nikomatsakis
…petrochenkov

Turn feature-gate table into a query so it is covered by dependency tracking.

Turn access to feature gates into a query so we handle them correctly during incremental compilation.

Features are still available via `Session` through `features_untracked()`. I wish we had a better way of hiding untracked information. It would be great if we could remove the `sess` field from `TyCtxt`.

Fixes rust-lang#47003.
…bank

Overhaul improper_ctypes output

This snowballed into a rather big set of improvements to the diagnostics of the improper_ctypes lint. See commits for details, including effects of each change on the `compile-fail/improper-ctypes.rs` test (now a UI test), which is pretty gnarly and hopefully not representative of real code, but covers a lot of different error cases.

Fixes rust-lang#42050
save-analysis: power through bracket mis-counts

Closes rust-lang#47981

This is pretty unsatisfying since it is working around a span bug. However, I can't track down the span bug and it could be in the parser, proc macro expansion, the user macro, or Syn (or any other library that can manipulate spans). Given that user code can cause this error, I think we need to be more robust here.

r? @eddyb
…illaumeGomez

Fix broken documentation link.

None
@rust-highfive
Copy link
Collaborator

r? @estebank

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

@Manishearth
Copy link
Member Author

@bors r+ p=100

@bors
Copy link
Contributor

bors commented Feb 19, 2018

📌 Commit c787251 has been approved by Manishearth

@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Feb 19, 2018
@bors
Copy link
Contributor

bors commented Feb 19, 2018

⌛ Testing commit c787251 with merge 53f34ecc897edbfe3d78782091f3794694bf78cf...

@bors
Copy link
Contributor

bors commented Feb 19, 2018

💔 Test failed - status-appveyor

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 19, 2018
@Centril Centril added the rollup A PR which is a rollup label Oct 24, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties.
Projects
None yet
Development

Successfully merging this pull request may close these issues.