Rustc pull update#2875
Merged
Merged
Conversation
fix incorrect suggestions in private import diagnostic Resolves rust-lang/rust#156060. 1. In nested imports like `use two::{One, ...}`, the diagnostic suggested replacing the `One` with a multi-segment path of a different module, producing invalid code like `use crate::two::{one::One, Two}`. Skip it when `single_nested == true`. 2. Stop unconditionally skipping the first segment of `import.module_path`, which can produce incorrect paths in edition 2018 and later. 3. Mark the suggestion as "directly" instead of "through the re-export" when the import's source is the definition itself.
rustc-dev-guide subtree update Subtree update of `rustc-dev-guide` to 34d6968. Created using https://github.com/rust-lang/josh-sync. r? @ghost
Rollup of 5 pull requests Successful merges: - rust-lang/rust#156141 (Resolve some cases of rust-lang/rust#132279 by using the right typing mode in the next solver) - rust-lang/rust#156244 (fix incorrect suggestions in private import diagnostic) - rust-lang/rust#156306 (Move tests consts) - rust-lang/rust#156333 (Avoid invalid spans in dotdotdot rest pattern suggestions) - rust-lang/rust#156337 (rustc-dev-guide subtree update)
Implement some trait for next solver's lang item enums rust-analyzer needs that.
…imulacrum `BufWriter`: Make the soundness of `BorrowedBuf` usage clearer. The previous safety comment was outdated as it was written before `BorrowedBuf::set_init` was changed to be a boolean. It also failed to address the possibility that `flush_buf` invalidated the assumption.
Consider `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` to be equivalent to `T` for must use lint This is an extension to rust-lang/rust#147382. With this PR `Result<T, Uninhabited>` and `ControlFlow<Uninhabited, T>` considered as must use iif `T` must be used. For such cases the lint will mention that `T` is wrapped in a `Result`/`ControlFlow` with an uninhabited error/break. The reasoning here is that `Result<T, Uninhabited>` is equivalent to `T` in which values can be represented and thus the must-used-ness should also be equivalent. Fixes rust-lang/rust#65861
remove forever-deprecated and hidden `f64` methods The methods `f64::is_positive` and `f64::is_negative` were deprecated since 1.0 and marked as `#[doc(hidden)]` in favor of `f64::is_sign_positive` and `f64::is_sign_negative`. They also only exist on `f64`, not on `f32`. But for some unknown reason, they have been marked as stable. This PR proposes to remove both methods as they were never a part of the documented API, assuming that a crater run finds no significant breakage.
By convention, compiletest directives starting with `ignore-*` normally cause the test itself to be skipped under certain conditions. The `//@ ignore-pass` directive was the only exception to that convention. The new name should hopefully do a better job of communicating its effect, which is to cause the `--pass` flag to not override the test's `build-pass` or `run-pass` directive. The `//@ no-pass-override` directive is mainly useful for tests that expect warnings produced during codegen.
compiletest: Rename `//@ ignore-pass` to `//@ no-pass-override` By convention, compiletest directives starting with `ignore-*` normally cause the test itself to be skipped under certain conditions. The `//@ ignore-pass` directive was the only exception to that convention. The new name should hopefully do a better job of communicating its effect, which is to cause the `--pass` flag to not override the test's `build-pass` or `run-pass` directive. The `//@ no-pass-override` directive is mainly useful for tests that expect warnings produced during codegen. --- r? jieyouxu
Rollup of 2 pull requests Successful merges: - rust-lang/rust#156450 (compiletest: Enforce that directives are consistently used with or without a colon) - rust-lang/rust#156531 (compiletest: Rename `//@ ignore-pass` to `//@ no-pass-override`)
remove `box_patterns` from remaining compiler crates Part of rust-lang/rust#156110.
map_try_insert changes Made changes according to rust-lang/rust#82766 (comment). r? @tgross35
DestinationPropagation: compute liveness as ranges instead of traveling bitsets The current implementation of `save_as_liveness` is very slow, and consists in inserting a traveling bitset in an interval set. As the `MaybeLiveLocals` has a gen-kill property, we can leverage it to make it faster. "Gen" is creating a new interval. "Kill" is ending this interval, ripe to save in the interval set.
…binarycat,mejrs rustdoc: properly support macros with multiple kinds Since it seems like I can't reopen rust-lang/rust#145458, opening this one. Although, it's the same PR minus the last new commit to handle a comment that was left unresolved in the original PR. All relevant details are still in the original PR though. It's an alternative (and likely a take-over) of rust-lang/rust#148005 since lang-team rejected the idea to add documentation on macro branches, making the multiple files approach less suitable. This implements rust-lang/rust#145153 in rustdoc. This PR voluntarily doesn't touch anything related to intra-doc links, I'll send a follow-up if needed. So now about the implementation itself: this is a weird case where a macro can be different things at once but still only gets one file generated. I saw two ways to implement this: 1. Handle `ItemKind::Macro` differently and iter through its `MacroKinds` values. 2. Add new placeholder variants in the `ItemKind` enum, which means that when we encounter them in rendering, we need to ignore them. It also makes the `ItemKind` enum bigger (and also needs more code to be handled). Another downside is that it needs to be handled in the JSON output. Now there was an interesting improvement that came with this PR in the `html::render::print_item::item_module` function: I simplified its implementation and split the different parts in a `HashMap` where the key is the item type. So then, we can just iterate through the keys and open/close the section at each iteration instead of keeping an `Option<section>` around. From RFCs: * rust-lang/rust#144579 * rust-lang/rust#145208 derive: <img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-40" src="https://github.com/user-attachments/assets/f69587a0-8a2b-4080-bc8a-b63dd18f21c1" /> attr: <img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-31" src="https://github.com/user-attachments/assets/bf9b235a-9d2f-435c-a91e-167562df6b68" /> both: <img width="442" height="327" alt="Screenshot From 2026-04-18 03-11-50" src="https://github.com/user-attachments/assets/b7e8b3c6-eb99-495b-bdf9-17ba8fb4da0d" /> r? @notriddle
[style] rustfmt `match`es with comments in or-patterns Using rust-lang/rustfmt#6893, I reformatted the whole codebase. The result is that `match`es that *should have* been formatted under normal circumstances but are getting skipped now got their expected format. These match expressions were being entirely skipped because they contain or-patterns with comments in between patterns, causing rustfmt to bail out entirely. The or-patterns with comments themselves remain untouched, but now the match arm bodies and other patterns without comments do get formatted under that PR. Because the fix in rustfmt isn't landed yet, I reworked some of the or-patterns with comments so that formatting doesn't regress. Tried doing this only in larger blocks that are more likely to regress in the meantime. (Introduced and) removed a bunch of stray backticks \` likely left after an editor autoclosed the intended closing \`, resulting in <code>\`name\`\`</code> in comments.
…tebank compiler: suggest `.collect()` when `String` is expected and `Iterator` is found This commit adds a diagnostic suggestion to help users who forget to call `.collect()` when they have an iterator and the function or variable expects a `String`. The logic checks if the expected type is `std::string::String` and if the found type implements the `Iterator` trait, if so the compiler provides a suggestion to add `.collect()` Includes also a UI test to verify if the suggestion appears correctly
explicit tail calls: ignore some tests on unsupported LLVM targets Fixes rust-lang/rust#148748 Add ignore derivatives to two tests that cause the most platforms to fail, there are two reasons: All tests involving `musttail` should fail on these platforms due to poor support overall by LLVM, but since they have low usage and supposedly already have many tests failing we limit ignores to the two "worst" tests. ``` //@ ignore-aix //@ ignore-csky //@ ignore-mips //@ ignore-mips64 //@ ignore-powerpc //@ ignore-powerpc64 //@ ignore-thumb ``` aix/powerpc issue: llvm/llvm-project#187119 thumb issue: llvm/llvm-project#73167 mips has been fixed but it is in a different LLVM version than what is pinned by Rust: llvm/llvm-project#57795 These were caused by argument/returns that do not fit in registers (e.g., indirect), they had a fix but were reverted due to lifetime issues: ``` //@ ignore-riscv64 //@ ignore-loongarch32 //@ ignore-loongarch64 ``` RISC-V had a fix which got reverted: llvm/llvm-project#191508 LoongArch fix also got reverted: llvm/llvm-project#191525 Also add missing compiletest directive names for `ignore-csky`, `ignore-mips`, and `ignore-mips64`. r? folkertdev
Avoid rustfix suggestions for macro-expanded unused imports Avoid emitting rustfix suggestions for unused imports when the removal span is not directly editable. Closes rust-lang/rust#147855
…omez rustdoc: add test case for `-Drustdoc::` and `--cap-lints` This works, but I couldn't find any test cases for it.
…001999 Add regression test for issue #41261 Adds a regression test for rust-lang/rust#41261.
…Titor rename unexpected_try_recover function While reading the code, the doc comment and the name of the function `unexpected_try_recover` confused me. The doc said it tries to recover if it is a closing delimiter but I see no recovering code and the function always return an error. So I change the name of the function to `unexpected_err` and change the return value to `Diag<'a>`. I also update the doc comment.
minor `rustc_mir_transform` cleanup Some minor things I noticed here and there while reading though code
…uwer Rollup of 14 pull requests Successful merges: - rust-lang/rust#151742 (Remove redundant information in `rustc_abi::Variants`) - rust-lang/rust#151362 (Add interior-mutability suggestion to `static_mut_refs`) - rust-lang/rust#156121 (compiler: suggest `.collect()` when `String` is expected and `Iterator` is found) - rust-lang/rust#156208 (Emit retags in codegen to support BorrowSanitizer (part 1)) - rust-lang/rust#156596 (Split `LintExpectationId`s) - rust-lang/rust#156607 (ci: Update FreeBSD version to FreeBSD 14) - rust-lang/rust#156376 (suggest hex escapes for C-style escapes) - rust-lang/rust#156577 (Test EII UI tests with prefer-dynamic) - rust-lang/rust#156585 (explicit tail calls: ignore some tests on unsupported LLVM targets) - rust-lang/rust#156598 (Avoid rustfix suggestions for macro-expanded unused imports) - rust-lang/rust#156616 (rustdoc: add test case for `-Drustdoc::` and `--cap-lints`) - rust-lang/rust#156633 (Add regression test for issue rust-lang/rust#41261) - rust-lang/rust#156635 (rename unexpected_try_recover function) - rust-lang/rust#156636 (minor `rustc_mir_transform` cleanup)
Include vendored sources in the rust-src component In the future this can be used by build-std, but until then it is still useful for allowing rust-analyzer to work offline. This increases the unpacked size by 24MB (from 116MB to 140MB) and the compressed size by only 2MB (from 18MB to 20MB)
Fix cross-compiling `macos-deployment-target-warning` test `cc()` gets target flags, which won't match with the host triple used by `bare_rustc()`. Follow-up to rust-lang/rust#155716, with both of these, `./x test --target arm64e-apple-darwin tests` now succeeds. r? compiler
remove/update various cfg(miri) I went over all `cfg(miri)` in `library/`. Most of the things I noticed have become separate PRs; these here are the few remaining scattered little fixes in various places.
doc(core::cmp::Eq): fix definition of symmetry The definition did not match the one from PartialEq
…, r=SimonSapin implement `into_array` for `Vec<T>` for more into_array coverage and to avoid harmful obtuse opaque try_into calls
Fix missing period in Iterator product doc comment It looks like the other doc comments all end with a period.
std: replace "safe" with "sound" in safety documentation - `env::set_var` - `env::remove_var` Context: rust-lang/rust#124636
…uwer Rollup of 13 pull requests Successful merges: - rust-lang/rust#156196 (Include vendored sources in the rust-src component) - rust-lang/rust#155870 (Fix cross-compiling `macos-deployment-target-warning` test) - rust-lang/rust#156492 (remove/update various cfg(miri)) - rust-lang/rust#156676 (Preserve spans when hiding do_not_recommend impls) - rust-lang/rust#155313 (doc(core::cmp::Eq): fix definition of symmetry) - rust-lang/rust#156234 (implement `into_array` for `Vec<T>`) - rust-lang/rust#156488 (Fix missing period in Iterator product doc comment) - rust-lang/rust#156572 (std: replace "safe" with "sound" in safety documentation) - rust-lang/rust#156624 (c ffi document fixes for c_short.md) - rust-lang/rust#156638 (library: Fix std compilation for espidf target in unix::process) - rust-lang/rust#156647 (Change division to multiplication in floating-point midpoint) - rust-lang/rust#156668 (Fix typo in `format_into` docs: signed -> unsigned) - rust-lang/rust#156677 (change `other uses of const` to `raw pointers` in const keyword docs)
This updates the rust-version file to a31c27a887b40df16ab9dfb8c9f7924636092509.
Pull recent changes from https://github.com/rust-lang/rust via Josh. Upstream ref: rust-lang/rust@a31c27a Filtered ref: 66a2aa8 Upstream diff: rust-lang/rust@f2b291d...a31c27a This merge was created using https://github.com/rust-lang/josh-sync.
Collaborator
|
Thanks for the PR. If you have write access, feel free to merge this PR if it does not need reviews. You can request a review using |
rustbot
added
the
S-waiting-on-review
rustbot
removed
the
S-waiting-on-review
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
8 participants
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.
Latest update from rustc.