Rollup of 9 pull requests #98447
Merged
Rollup of 9 pull requests #98447
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
…ctually querying it
In fc35703 `#[main]` was removed and replaced with `#[rustc_main]`. In some place the rename was forgotten, which makes the current code confusing, because at first glance it seems that `#[main]` is still around. Perform the renames also in these places.
This moves us a step closer to removing the `PartialOrd/`Ord` impls for `DefId`. See rust-lang#90317
This adapts LLVM's behavior of MCELFObjectTargetWriter::getOSABI [1]. [1]: https://github.com/llvm/llvm-project/blob/8c8a2679a20f621994fa904bcfc68775e7345edc/llvm/include/llvm/MC/MCELFObjectWriter.h#L72-L86
…=jsha Add macro support in jump to definition feature Fixes rust-lang#91174. To do so, I check if the span comes from an expansion, and if so, I infer the original macro `DefId` or `Span` depending if it's a defined in the current crate or not. There is one limitation due to macro expansion though: ```rust macro_rules! yolo { () => {}} fn foo() { yolo!(); } ``` In `foo`, `yolo!` won't be linked because after expansion, it is replaced by nothing (which seems logical). So I can't get an item from the `Visitor` from which I could tell if its `Span` comes from an expansion. I added a test for this specific limitation alongside others. Demo: https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html As for the empty macro issue that cannot create a jump to definition, you can see it [here](https://rustdoc.crud.net/imperio/macro-jump-to-def/src/foo/check-source-code-urls-to-def-std.rs.html#35). r? ```@jyn514```
…ochenkov Remove (transitive) reliance on sorting by DefId in pretty-printer This moves us a step closer to removing the `PartialOrd/`Ord` impls for `DefId`. See rust-lang#90317
Session object: Set OS/ABI Closes rust-lang#97535. This depends on * gimli-rs/object#438 This adapts LLVM's behavior of [`MCELFObjectTargetWriter::getOSABI`](https://github.com/llvm/llvm-project/blob/8c8a2679a20f621994fa904bcfc68775e7345edc/llvm/include/llvm/MC/MCELFObjectWriter.h#L72-L86).
Fix `panic` message for `BTreeSet`'s `range` API and document `panic` cases Currently, the `panic` cases for [`BTreeSet`'s `range` API](https://doc.rust-lang.org/std/collections/struct.BTreeSet.html#method.range) are undocumented and produce a slightly wrong `panic` message (says `BTreeMap` instead of `BTreeSet`). Panic case 1 code: ```rust use std::collections::BTreeSet; use std::ops::Bound::Excluded; fn main() { let mut set = BTreeSet::new(); set.insert(3); set.insert(5); set.insert(8); for &elem in set.range((Excluded(&3), Excluded(&3))) { println!("{elem}"); } } ``` Panic case 1 message: ``` thread 'main' panicked at 'range start and end are equal and excluded in BTreeMap', /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/collections/btree/search.rs:105:17 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` Panic case 2 code: ```rust use std::collections::BTreeSet; use std::ops::Bound::Included; fn main() { let mut set = BTreeSet::new(); set.insert(3); set.insert(5); set.insert(8); for &elem in set.range((Included(&8), Included(&3))) { println!("{elem}"); } } ``` Panic case 2: ``` thread 'main' panicked at 'range start is greater than range end in BTreeMap', /rustc/fe5b13d681f25ee6474be29d748c65adcd91f69e/library/alloc/src/collections/btree/search.rs:110:17 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace ``` This PR fixes the output messages to say `BTreeSet`, adds the relevant unit tests, and updates the documentation for the API.
rustc_target: Remove some redundant target properties
`is_like_emscripten` is equivalent to `os == "emscripten"`, so it's removed.
`is_like_fuchsia` is equivalent to `os == "fuchsia"`, so it's removed.
`is_like_osx` also falls into the same category and is equivalent to `vendor == "apple"`, but it's commonly used so I kept it as is for now.
`is_like_(solaris,windows,wasm)` are combinations of different operating systems or architectures (see compiler/rustc_target/src/spec/tests/tests_impl.rs) so they are also kept as is.
I think `is_like_wasm` (and maybe `is_like_osx`) are sufficiently closed sets, so we can remove these fields as well and replace them with methods like `fn is_like_wasm() { arch == "wasm32" || arch == "wasm64" }`.
On other hand, `is_like_solaris` and `is_like_windows` are sufficiently open and I can imagine custom targets introducing other values for `os`.
This is kind of a gray area.
…-on-type-err, r=estebank Improve suggestion for calling fn-like expr on type mismatch 1.) Suggest calling values of with RPIT types (and probably TAIT) when we expect `Ty` and have `impl Fn() -> Ty` 2.) Suggest calling closures even when they're not assigned to a local variable first 3.) Drive-by fix of a pretty-printing bug (`impl Fn()-> Ty` => `impl Fn() -> Ty`) r? ```@estebank```
…=petrochenkov Fixup missing renames from `#[main]` to `#[rustc_main]` In rust-lang#84217 `#[main]` was removed and replaced with `#[rustc_main]`. In some places the rename was forgotten, which makes the current code confusing, because at first glance it seems that `#[main]` is still around. Perform the renames also in these places. I noticed this (after first being confused by it) when working on rust-lang#97802. r? `@petrochenkov` (since you reviewed the other PR)
…crum Update tendril The 0.4.1 version of `tendril` (used by mdbook) triggers the `unaligned_references` lint which is now reported as a future-compatibility warning as of rust-lang#95372. This updates it to 0.4.3 which does not trigger the warning. This update also triggered the update of `futf` from 0.1.4 to 0.1.5. tendril changes: servo/tendril@v0.4.1...v0.4.3 futf changes: servo/futf@v0.1.4...v0.1.5
…ompiler-errors Remove excess rib while resolving closures I've mentioned this on [zulip](https://rust-lang.zulipchat.com/#narrow/stream/131828-t-compiler/topic/.60ClosureOrAsyncRibKind.60.20weirdness/near/286982959), in `rustc_resolve`, while resolving closures we add an excess `ClosureOrAsyncRibKind`. It's excess because we later add another one in `visit_fn`. I couldn't find a way in which removing this will break anything, all test seem to pass, etc. r? ``@compiler-errors`` cc ``@davidtwco``
rustbot
added
T-compiler
|
@bors r+ rollup=never p=9 |
|
📌 Commit 5e98e55 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
This was referenced Jun 24, 2022
|
Finished benchmarking commit (7036449): comparison url. Instruction count
Max RSS (memory usage)Results
CyclesResults
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
|
The regressions are contained to only one test case (regex opt) in codegen related queries. I didn't find any PRs that seemed like likely culprits. Marking as triaged. @rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
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:
panicmessage forBTreeSet'srangeAPI and documentpaniccases #98039 (Fixpanicmessage forBTreeSet'srangeAPI and documentpaniccases)#[main]to#[rustc_main]#98394 (Fixup missing renames from#[main]to#[rustc_main])Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup