Rollup of 8 pull requests #70305
Merged
Rollup of 8 pull requests #70305
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
This reverts commit 8b9c539.
Brings in WebAssembly/wasi-libc#184 which can help standalone programs with environment variables!
…-a-bar, r=michaelwoerister rustc_codegen_llvm: don't generate any type debuginfo for -Cdebuginfo=1. Works towards rust-lang#69074 by adding more checks for `DebugInfo::Full` in a few places in `rustc_codegen_llvm`, bringing us in line with what `clang -g1` generates (no debuginfo types, nor debuginfo for `static`s). <hr/> My local build's (`debuginfo-level=1`, `debug-assertions=1`) `librustc_driver-*.so` went from just over 1GiB (1019MiB) down to 402MiB. It's still bad, but the `.debug_*` sections themselves (as reported by `objdump`) went from something like 853MiB down to 236MiB, i.e. roughly a 3.6x reduction. <hr/> Sadly, I don't think this is enough to justify *shipping* all of this debuginfo, but now it's more plausible that we could at least *build* with `debuginfo-level=1` *then* strip it. That would give us real backtraces for e.g. ICEs during builds, but I don't know how often that's relevant. We could also look into split DWARF, and maybe have a `rustc-debuginfo` component in `rustup`. There's also the possibility of making it slimmer by omitting parameters to functions, or perhaps some deduplication (I think right now there is no DWARF reuse across CGUs? maybe ThinLTO helps?). r? @michaelwoerister cc @rust-lang/wg-codegen @alexcrichton @Mark-Simulacrum
librustc_codegen_llvm: Replace deprecated API usage
…hewjasper Increase verbosity when suggesting subtle code changes Do not suggest changes that are actually quite small inline, to minimize the likelihood of confusion. Fix rust-lang#69243.
…komatsakis
rustc: keep upvars tupled in {Closure,Generator}Substs.
Previously, each closure/generator capture's (aka "upvar") type was tracked as one "synthetic" type parameter in the closure/generator substs, and figuring out where the parent `fn`'s generics end and the synthetics start involved slicing at `tcx.generics_of(def_id).parent_count`.
Needing to query `generics_of` limited @davidtwco (who wants to compute some `TypeFlags` differently for parent generics vs upvars, and `TyCtxt` is not available there), which is how I got started on this, but it's also possible that the `generics_of` queries are slowing down `{Closure,Generator}Substs` methods.
To give an example, for a `foo::<T, U>::{closure#0}` with captures `x: X` and `y: Y`, substs are:
* before this PR: `[T, U, /*kind*/, /*signature*/, X, Y]`
* after this PR: `[T, U, /*kind*/, /*signature*/, (X, Y)]`
You can see that, with this PR, no matter how many captures, the last 3 entries in the substs (or 5 for a generator) are always the "synthetic" ones, with the last one being the tuple of capture types.
r? @nikomatsakis cc @Zoxc
…crum Ensure LLVM is in the link path for rustc tools The build script for `rustc_llvm` outputs LLVM information in `cargo:rustc-link-lib` and `cargo:rustc-link-search` so the compiler can be linked correctly. However, while the lib is carried along in metadata, the search paths are not. So when cargo is invoked again later for rustc _tools_, they'll also try to link with LLVM, but the necessary paths may be left out. Rustbuild can use the environment to set the LLVM link path for tools -- `LIB` for MSVC toolchains and `LIBRARY_PATH` for everyone else. Fixes rust-lang#68714.
…lbini Update the bundled wasi-libc with libstd Brings in WebAssembly/wasi-libc#184 which can help standalone programs with environment variables!
…morse resolve: Do not resolve visibilities on proc macro definitions twice Fixes rust-lang#68921
…nkov Miri error type: remove UbExperimental variant In rust-lang/miri#1250, I will move Miri away from that variant, and use a custom `MachineStop` exception instead.
|
@bors r+ p=8 rollup=never |
|
📌 Commit 07e1043 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-azure |
|
📣 Toolstate changed by #70305! Tested on commit 5aa8f19. 💔 clippy-driver on windows: test-pass → build-fail (cc @mcarton @oli-obk @Manishearth @flip1995 @yaahc @phansch @llogiq). |
rust-highfive
added a commit
to rust-lang-nursery/rust-toolstate
that referenced
this pull request
Mar 23, 2020
Tested on commit rust-lang/rust@5aa8f19. Direct link to PR: <rust-lang/rust#70305> 💔 clippy-driver on windows: test-pass → build-fail (cc @mcarton @oli-obk @Manishearth @flip1995 @yaahc @phansch @llogiq). 💔 clippy-driver on linux: test-pass → build-fail (cc @mcarton @oli-obk @Manishearth @flip1995 @yaahc @phansch @llogiq). 💔 miri on windows: test-fail → build-fail (cc @oli-obk @eddyb @RalfJung). 💔 miri on linux: test-fail → build-fail (cc @oli-obk @eddyb @RalfJung).
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.
Successful merges:
Failed merges:
r? @ghost