Skip to content

Conversation

@tmandry
Copy link
Member

@tmandry tmandry commented Sep 10, 2020

Successful merges:

Failed merges:

r? @ghost

matthiaskrgr and others added 20 commits September 8, 2020 11:32
…e they are no longer supported by llvm CMake Warning: Manually-specified variables were not used by the project: PYTHON_EXECUTABLE WITH_POLLY
The only link that I did not change is a link to a function on the `pointer` primitive because intra-doc links for the `pointer` primitive don't work yet (see rust-lang#63351).
Many developers use a dark theme with editors and IDEs, but this typically doesn't extend to graphviz output. When I bring up a MIR graphviz document, the white background is strikingly bright. This new option changes the colors used for graphviz output to work better in dark-themed UIs.
`write` is ambiguous because there's also a macro called `write`. Also removed unnecessary and potentially confusing link to a function in its own docs.
#safety -> self#safety
VS code graphviz extensions use d3-graphviz, which supports `Courier` fontname but does not support `monospace`. This caused graphs to render poorly because the text sizes were wrong.
…etrochenkov" This reverts commit 85cee57, reversing changes made to b4d3873.
Move `rustllvm` into `compiler/rustc_llvm` The `rustllvm` directory is not self-contained, it contains C++ code built by a build script of the `rustc_llvm` crate which is then linked into that crate. So it makes sense to make `rustllvm` a part of `rustc_llvm` and move it into its directory. I replaced `rustllvm` with more obvious `llvm-wrapper` as the subdirectory name, but something like `llvm-adapter` would work as well, other suggestions are welcome. To make things more confusing, the Rust side of FFI functions defined in `rustllvm` can be found in `rustc_codegen_llvm` rather than in `rustc_llvm`. Perhaps they need to be moved as well, but this PR doesn't do that. The presence of multiple LLVM-related directories in `src` (`llvm-project`, `rustllvm`, `librustc_llvm`, `librustc_codegen_llvm` and their predecessors) historically confused me and made me wonder about their purpose. With this PR we will have LLVM itself (`llvm-project`), a FFI crate (`rustc_llvm`, kind of `llvm-sys`) and a codegen backend crate using LLVM through the FFI crate (`rustc_codegen_llvm`).
Add drain_filter method to HashMap and HashSet Add `HashMap::drain_filter` and `HashSet::drain_filter`, implementing part of rust-lang/rfcs#2140. These new methods are unstable. The tracking issue is rust-lang#59618. The added iterators behave the same as `BTreeMap::drain_filter` and `BTreeSet::drain_filter`, except their iteration order is arbitrary. The unit tests are adapted from `alloc::collections::btree`. This branch rewrites `HashSet` to be a wrapper around `hashbrown::HashSet` rather than `std::collections::HashMap`. (Both are themselves wrappers around `hashbrown::HashMap`, so the in-memory representation is the same either way.) This lets `std` re-use more iterator code from `hashbrown`. Without this change, we would need to duplicate much more code to implement `HashSet::drain_filter`. This branch also updates the `hashbrown` crate to version 0.9.0. Aside from changes related to the `DrainFilter` iterators, this version only changes features that are not used in libstd or rustc. And it updates `indexmap` to version 1.6.0, whose only change is compatibility with `hashbrown` 0.9.0.
…k-Simulacrum rustbuild: don't set PYTHON_EXECUTABLE and WITH_POLLY cmake vars since they are no longer supported by llvm This resolves CMake Warning: Manually-specified variables were not used by the project: PYTHON_EXECUTABLE WITH_POLLY
…r, r=jyn514 Use intra-doc links in `core::ptr` Part of rust-lang#75080. The only link that I did not change is a link to a function on the `pointer` primitive because intra-doc links for the `pointer` primitive don't work yet (see rust-lang#63351). --- @rustbot modify labels: A-intra-doc-links T-doc
Add -Zgraphviz_dark_mode and monospace font fix Many developers use a dark theme with editors and IDEs, but this typically doesn't extend to graphviz output. When I bring up a MIR graphviz document, the white background is strikingly bright. This new option changes the colors used for graphviz output to work better in dark-themed UIs. <img width="1305" alt="Screen Shot 2020-09-09 at 3 00 31 PM" src="https://user-images.githubusercontent.com/3827298/92659478-4b9bff00-f2ad-11ea-8894-b40d3a873cb9.png"> Also fixed the monospace font for common graphviz renders (e.g., VS Code extensions), as described in rust-lang#76500 (comment) **Before:** <img width="943" alt="Screen Shot 2020-09-09 at 2 48 44 PM" src="https://user-images.githubusercontent.com/3827298/92658939-47231680-f2ac-11ea-97ac-96727e4dd622.png"> **Now with fix:** <img width="943" alt="Screen Shot 2020-09-09 at 2 49 02 PM" src="https://user-images.githubusercontent.com/3827298/92658959-51451500-f2ac-11ea-9aae-de982d466d6a.png">
…ulacrum Document btree's unwrap_unchecked rust-lang#74693's second wind
Revert rust-lang#76285 Fixes rust-lang#76399. Reverting because the issue is P-critical and there are no PRs up to fix it. r? @Mark-Simulacrum cc @matklad @dtolnay
@tmandry
Copy link
Member Author

tmandry commented Sep 10, 2020

@bors r+ p=5 rollup=never
@rustbot modify labels: +rollup

@bors
Copy link
Collaborator

bors commented Sep 10, 2020

📌 Commit 193503e has been approved by tmandry

@rustbot rustbot added the rollup A PR which is a rollup label Sep 10, 2020
@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 Sep 10, 2020
@bors
Copy link
Collaborator

bors commented Sep 10, 2020

⌛ Testing commit 193503e with merge a1894e4...

@bors
Copy link
Collaborator

bors commented Sep 10, 2020

☀️ Test successful - checks-actions, checks-azure
Approved by: tmandry
Pushing a1894e4 to master...

@bors bors added the merged-by-bors This PR was explicitly merged by bors. label Sep 10, 2020
@bors bors merged commit a1894e4 into rust-lang:master Sep 10, 2020
@rustbot rustbot added this to the 1.48.0 milestone Sep 10, 2020
@tmandry tmandry deleted the rollup-bskim2r branch September 10, 2020 06:57
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merged-by-bors This PR was explicitly merged by bors. rollup A PR which is a rollup S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.

9 participants