Rollup of 16 pull requests #48348
Closed
Rollup of 16 pull requests #48348
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Member
Manishearth
commented
Feb 19, 2018
Manishearth
commented
- Successful merges: macros: improve struct constructor field hygiene, fix span bug #48082, Improve tuple struct field access hygiene #48083, Error on nested impl Trait and path projections from impl Trait #48084, rustdoc: move manual "extern crate" statements outside automatic "fn main"s in doctests #48106, detect wrong number of args when type-checking a closure #48123, rust: Import LLD for linking wasm objects #48125, Add Iterator::try_for_each #48157, incr.comp.: Don't keep RefCells in on-disk-cache borrowed in order to allow for recursive invocations. #48185, Allow two-phase borrows of &mut self in ops #48197, inform user where to give a type annotation #48198, incr.comp.: Store DepNode colors in a dense array instead of a hashmap. #48206, Turn feature-gate table into a query so it is covered by dependency tracking. #48208, Overhaul improper_ctypes output #48221, save-analysis: power through bracket mis-counts #48258, Fix broken documentation link. #48314, Implement implied shortcut links for intra-rustdoc-links #48335
- Failed merges:
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.
… allow for recursive invocations.
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
…Misdreavus Implement implied shortcut links for intra-rustdoc-links cc rust-lang#43466 Needs pulldown-cmark/pulldown-cmark#126 r? @QuietMisdreavus
|
r? @estebank (rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors r+ p=100 |
|
📌 Commit c787251 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit c787251 with merge 53f34ecc897edbfe3d78782091f3794694bf78cf... |
|
💔 Test failed - status-appveyor |
bors
added
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.