Rollup of 8 pull requests #98442
Closed
Rollup of 8 pull requests #98442
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
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
When cross compiling LLVM on an arm64 machine to x86_64, CMake will produce universal binaries by default, causing link errors. Explicitly set CMAKE_OSX_ARCHITECTURES to the one single target architecture.
When cross compiling rustc with `llvm.clang = true`, CLANG_TABLEGEN has to be set to the host clang-tblgen executable to build clang.
…=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``
Fix several issues during cross compiling - When cross compiling LLVM on an arm64 macOS machine to x86_64, CMake will produce universal binaries by default, causing link errors. Explicitly set `CMAKE_OSX_ARCHITECTURES` to the one single target architecture so that the executables and libraries will be single architecture. - When cross compiling rustc with `llvm.clang = true`, `CLANG_TABLEGEN` has to be set to the host `clang-tblgen` executable to build clang.
…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=8 |
|
📌 Commit 3c62245 has been approved by |
bors
added
the
S-waiting-on-bors
|
⌛ Testing commit 3c62245 with merge 7ec3cf17b3759ffca8186d1b1d75f25e857532a1... |
|
💔 Test failed - checks-actions |
bors
added
S-waiting-on-review
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup