Rollup of 12 pull requests #151129
Closed
Rollup of 12 pull requests #151129
+902
−541
Conversation
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
... in macro invocations. Issue: <rust-lang#149692>.
There's no sensible recovery scheme here, giving up the recovery is the right thing to do.
Previously, these failed to resolve, despite them working for struct fields or enum variants that were behind aliases. However, there is now an inconsistency where enum variant fields behind an alias resolve to the entry on the alias's page, while enum variants and struct fields resolve to the page of the backing ADT.
The old name and API were confusing. In my opinion, looking up the type at the call site is clearer.
All the other parts of this function return the Res for the containing page, but for some reason, this returns the associated item itself. It doesn't seem to affect the behavior of rustdoc because e.g. the href functions use the parent if the DefId is for an assoc item. But it's clearer and simpler to be consistent.
Otherwise eiis defined by std will produce large amounts of `missing stability attribute` errors.
target_arch for powerpc64le- targets is "powerpc64".
Recent changes made WASI targets use the Unix threading implementation, but WASI does not support threading. When the Unix code tries to call pthread_create, it fails with EAGAIN, causing libraries like rayon to panic when trying to initialize their global thread pool. This fix adds an early return in Thread::new() that checks for WASI and returns UNSUPPORTED_PLATFORM. This approach: - Continues using most of the unix.rs code path (less invasive) - Only requires a small cfg check at the start of Thread::new() - Can be easily removed once wasi-sdk is updated with the proper fix The real fix is being tracked in `WebAssembly/wasi-libc#716` which will change the error code returned by pthread_create to properly indicate unsupported operations. Once that propagates to wasi-sdk, this workaround can be removed. Fixes the regression where rayon-based code (e.g., lopdf in PDF handling) panicked on WASI after nightly-2025-12-10. Before fix: pthread_create returns EAGAIN (error code 6) ThreadPoolBuildError { kind: IOError(Os { code: 6, kind: WouldBlock, message: "Resource temporarily unavailable" }) } After fix: Thread::new returns Err(io::Error::UNSUPPORTED_PLATFORM) Libraries can gracefully handle the lack of threading support
The opposite ordering was a consistent source of confusion during debuggingю `report_conflict` actually used an incorrect order due to similar confusion.
Also avoid losing some glob ambiguities when re-fetching globs
Add a context-consistency check before emitting redundant generic-argument suggestions Fixes rust-lang#149559 Add a context-consistency check before emitting redundant generic-argument suggestions. If the redundant argument spans come from mixed hygiene contexts (e.g., macro definition + macro callsite), we skip the suggestion to avoid malformed `shrink_to_hi().to(...)` spans and potential ICEs.
…Gomez rustdoc: Fix intra-doc link bugs involving type aliases and associated items This PR: - Add support for linking to fields of variants behind a type alias. - Correctly resolve links to fields and variants behind a type alias to the alias's version of the docs. - Refactor some intra-doc links code to make it simpler. - Add tests for the status quo of linking to associated items behind aliases. Future steps: - Nail down the rules of when inherent and trait impls are inlined into an alias's docs, and when impls on the alias appear for the aliased type. - Adjust the resolutions of intra-doc links, through aliases, to associated items based on these rules. r? @GuillaumeGomez
Don't try to recover keyword as non-keyword identifier Fixes rust-lang#149692. On beta after rust-lang#146978, we ICE on ```rs macro_rules! m { ($id:item()) => {} } m!(Self()); ``` where `Self` in the macro invocation is a keyword not a "normal" identifier, while attempting to recover an missing keyword before an identifier. Except, `Self` *is* a keyword, so trying to parse that as a non-reserved identifier expectedly fails. I suspect rust-lang#146978 merely unmasked a possible code path to hit this case; this logic has been so for a good while. Previously, on stable, the error message looks something like ```rs error: expected identifier, found keyword `Self` --> src/lib.rs:5:4 | 5 | m!(Self()); | ^^^^ expected identifier, found keyword error: missing `fn` or `struct` for function or struct definition --> src/lib.rs:5:4 | 2 | ($id:item()) => {} | -------- while parsing argument for this `item` macro fragment ... 5 | m!(Self()); | ^^^^ | help: if you meant to call a macro, try | 5 | m!(Self!()); | + ``` I considered restoring this diagnostic, but I'm not super convinced it's worth the complexity (and to me, it's not super clear what the user actually intended here).
… r=lcnr cleanup: remove borrowck handling for inline const patterns rust-lang#120390 added borrow-checking for inline const patterns; a type annotation was added to inline const patterns in the THIR to remember the `DefId` and args of the constants so they could be checked and constraints could be propagated to their parents. As of rust-lang#138499 though, inline const patterns can't be borrow-checked due to a query cycle, and as of rust-lang#149667, the type/`DefId`/args annotations on inline const patterns have been removed, so the borrowck code for them seems unused; this PR removes it. In a hypothetical future where borrowck doesn't depend on exhaustiveness checking so `inline_const_pat` can be reinstated, I imagine we also won't be evaluating inline const patterns before borrowck. As such, we might be able to reuse the existing code for normal unevaluated inline const operands in [`TypeChecker::visit_operand`](https://github.com/rust-lang/rust/blob/32fe406b5e71afbb0d8b95280e50e67d1549224c/compiler/rustc_borrowck/src/type_check/mod.rs#L1720-L1749) (or at least we shouldn't need to encode inline const patterns' `DefId` and args in user type annotations if they appear directly in the MIR). r? lcnr
resolve: Relax some asserts in glob overwriting and add tests Fixes rust-lang#150927. Fixes rust-lang#150928. Fixes rust-lang#150929. Fixes rust-lang#150976. Fixes rust-lang#150977. Fixes rust-lang#151008. Fixes rust-lang#151037. Fixes rust-lang/rust-clippy#16398. r? @yaahc
rustbot
added
A-CI
Contributor
Author
|
@bors r+ rollup=never p=5 |
rustbot
added
T-bootstrap
rust-bors
bot
added
S-waiting-on-bors
Contributor
This comment has been minimized.
This comment has been minimized.
rust-bors bot
pushed a commit
that referenced
this pull request
Jan 14, 2026
…uwer Rollup of 12 pull requests Successful merges: - #150585 (Add a context-consistency check before emitting redundant generic-argument suggestions) - #150586 (rustdoc: Fix intra-doc link bugs involving type aliases and associated items) - #150590 (Don't try to recover keyword as non-keyword identifier ) - #150817 (cleanup: remove borrowck handling for inline const patterns) - #150939 (resolve: Relax some asserts in glob overwriting and add tests) - #150966 (rustc_target: Remove unused Arch::PowerPC64LE) - #150971 (Disallow eii in statement position) - #151016 (fix: WASI threading regression by disabling pthread usage) - #151046 (compiler: Make Externally Implementable Item (eii) macros "semiopaque") - #151103 (mir_build: Simplify length-determination and indexing for array/slice patterns) - #151117 (Avoid serde dependency in build_helper when not necessary) - #151127 (Delete `MetaItemOrLitParser::Err`) r? @ghost
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
rust-bors
bot
added
S-waiting-on-review
Contributor
|
💔 Test for dd481ba failed: CI. Failed jobs:
|
Contributor
Author
|
Not sure, probably #151103 |
rustbot
removed
the
S-waiting-on-review
This was referenced Jan 14, 2026
rust-bors bot
pushed a commit
that referenced
this pull request
Jan 15, 2026
Revert "avoid phi node for pointers flowing into Vec appends #130998" This reverts PR #130998 because the added test seems to be flaky / non-deterministic, and has been failing in unrelated PRs during merge CI: - #151129 (comment) - #150772 (comment) - #150925 (comment) See also [#t-infra > Tree ops](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Tree.20ops/with/568111767). > [!NOTE] > > This is a "fallback" PR in case the FileCheck failure isn't obvious (i.e. fix-forward). This PR reverts #130998 wholesale in case the failure is genuine and indicative of a bug in the actual implementation change.
Zalathar
added a commit
to Zalathar/rust
that referenced
this pull request
Jan 15, 2026
Revert "avoid phi node for pointers flowing into Vec appends rust-lang#130998" This reverts PR rust-lang#130998 because the added test seems to be flaky / non-deterministic, and has been failing in unrelated PRs during merge CI: - rust-lang#151129 (comment) - rust-lang#150772 (comment) - rust-lang#150925 (comment) - rust-lang#151145 (comment) See also [#t-infra > Tree ops](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Tree.20ops/with/568111767). > [!NOTE] > > This is a "fallback" PR in case the FileCheck failure isn't obvious (i.e. fix-forward). This PR reverts rust-lang#130998 wholesale in case the failure is genuine and indicative of a bug in the actual implementation change.
rust-timer
added a commit
that referenced
this pull request
Jan 15, 2026
Rollup merge of #151150 - revert-vec-append, r=Zalathar Revert "avoid phi node for pointers flowing into Vec appends #130998" This reverts PR #130998 because the added test seems to be flaky / non-deterministic, and has been failing in unrelated PRs during merge CI: - #151129 (comment) - #150772 (comment) - #150925 (comment) - #151145 (comment) See also [#t-infra > Tree ops](https://rust-lang.zulipchat.com/#narrow/channel/242791-t-infra/topic/Tree.20ops/with/568111767). > [!NOTE] > > This is a "fallback" PR in case the FileCheck failure isn't obvious (i.e. fix-forward). This PR reverts #130998 wholesale in case the failure is genuine and indicative of a bug in the actual implementation change.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
15 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.
Successful merges:
MetaItemOrLitParser::Err#151127 (DeleteMetaItemOrLitParser::Err)r? @ghost
Create a similar rollup