Skip to content

Rollup of 9 pull requests #142180

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 28 commits into from

Conversation

GuillaumeGomez
Copy link
Member

@GuillaumeGomez GuillaumeGomez commented Jun 7, 2025

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

Urgau and others added 28 commits May 22, 2025 19:12
also unify error messages that do not seem to have a good reason to be different
…illaumeGomez

Allow `#![doc(test(attr(..)))]` everywhere

This PR adds the ability to specify [`#![doc(test(attr(..)))]`](https://doc.rust-lang.org/nightly/rustdoc/write-documentation/the-doc-attribute.html#testattr) ~~at module level~~ everywhere in addition to allowing it at crate-root.

This is motivated by a recent PR rust-lang#140323 (by ```@tgross35)``` where we have to duplicate 2 attributes to every single `f16` and `f128` doctests, by allowing `#![doc(test(attr(..)))]` at module level (and everywhere else) we can omit them entirely and just have (in both module):

```rust
#![doc(test(attr(feature(cfg_target_has_reliable_f16_f128))))]
#![doc(test(attr(expect(internal_features))))]
```

Those new attributes are appended to the one found at crate-root or at a previous module. Those "global" attributes are compatible with merged doctests (they already were before).

Given the small addition that this is, I'm proposing to insta-stabilize it, but I can feature-gate it if preferred.

Best reviewed commit by commit.

r? ```@GuillaumeGomez```
…ntions, r=workingjubilee

Add (back) `unsupported_calling_conventions` lint to reject more invalid calling conventions

This adds back the `unsupported_calling_conventions` lint that was removed in rust-lang#129935, in order to start the process of dealing with rust-lang#137018. Specifically, we are going for the plan laid out [here](rust-lang#137018 (comment)):
- thiscall, stdcall, fastcall, cdecl should only be accepted on x86-32
- vectorcall should only be accepted on x86-32 and x86-64

The difference to the status quo is that:
- We stop accepting stdcall, fastcall on targets that are windows && non-x86-32 (we already don't accept these on targets that are non-windows && non-x86-32)
- We stop accepting cdecl on targets that are non-x86-32
- (There is no difference for thiscall, this was already a hard error on non-x86-32)
- We stop accepting vectorcall on targets that are windows && non-x86-*

Vectorcall is an unstable ABI so we can just make this a hard error immediately. The others are stable, so we emit the `unsupported_calling_conventions` forward-compat lint. I set up the lint to show up in dependencies via cargo's future-compat report immediately, but we could also make it show up just for the local crate first if that is preferred.
…ignore_ascii_case, r=Mark-Simulacrum

Stabilize `const_eq_ignore_ascii_case`

Tracking issue: rust-lang#131719
Closes rust-lang#131719
FCP Completed: rust-lang#131719 (comment)
…elate, r=BoxyUwU

Treat normalizing consts like normalizing types in deeply normalize

...so that we don't end up putting a top-level normalizes-to goal in the fulfillment context, which ICEs. This basically just models the normalize-const code off of the normalize-ty code above it, which uses an alias-relate goal instead.

Fixes rust-lang#140571

r? lcnr
…iants, r=bjorn3

compiler: Sort and doc ExternAbi variants

My personal brainworms found this ordering made the most sense while writing the CanonAbi PR.  It is *an* ordering, at least, unlike the current mess. There has been no particular reason for the previous order ever since rust-lang#136901, despite the comment I delete here. I just didn't change it.

Because I feel weird just fussing with variant ordering in the source definition, I also documented a bunch to the best of my ability.
…arn, r=Urgau

compiler: Treat ForceWarning as a Warning for diagnostic level

This silences an ICE.

No idea if this is the correct solution though tbh.

Fixes rust-lang#142144
…oli-obk

get rid of spurious cfg(bootstrap)

r? ``@oli-obk``
@rustbot rustbot added A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs labels Jun 7, 2025
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) rollup A PR which is a rollup labels Jun 7, 2025
@GuillaumeGomez
Copy link
Member Author

@bors r+ p=5 rollup=never

@bors
Copy link
Collaborator

bors commented Jun 7, 2025

📌 Commit 292562e has been approved by GuillaumeGomez

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Jun 7, 2025
@workingjubilee
Copy link
Member

@bors r- Sorry, I diagnosed the broken rollup and this has the bad PR.

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Jun 7, 2025
@GuillaumeGomez
Copy link
Member Author

No problem, thanks!

@GuillaumeGomez GuillaumeGomez deleted the rollup-ytymvu7 branch June 7, 2025 20:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-attributes Area: Attributes (`#[…]`, `#![…]`) A-run-make Area: port run-make Makefiles to rmake.rs rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. T-rustdoc-frontend Relevant to the rustdoc-frontend team, which will review and decide on the web UI/UX output. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants