Skip to content

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