Uh oh!
There was an error while loading. Please reload this page.
Rollup of 9 pull requests - #142180
Closed
GuillaumeGomez wants to merge 28 commits into
Closed
Conversation
…d calling conventions
also unify error messages that do not seem to have a good reason to be different
This silences an ICE.
…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.
…Jung Document representation of `Option<unsafe fn()>` https://rust-lang.zulipchat.com/#narrow/channel/136281-t-opsem/topic/Option.20Layout.20with.20.60fn.60.20pointers/with/520055652
…ignore_ascii_case, r=Mark-Simulacrum Stabilize `const_eq_ignore_ascii_case` Tracking issue: rust-lang#131719Closesrust-lang#131719 FCP Completed: rust-lang#131719 (comment)
…acrum Fix bootstrap tracing imports
…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. Fixesrust-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. Fixesrust-lang#142144
…oli-obk get rid of spurious cfg(bootstrap) r? ``@oli-obk``
GuillaumeGomez
commented
Jun 7, 2025
MemberAuthor
@bors r+ p=5 rollup=never |
bors
commented
Jun 7, 2025
Collaborator
workingjubilee
commented
Jun 7, 2025
Member
@bors r- Sorry, I diagnosed the broken rollup and this has the bad PR. |
GuillaumeGomez
commented
Jun 7, 2025
MemberAuthor
No problem, thanks! |
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 freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
10 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:
#![doc(test(attr(..)))]everywhere #140560 (Allow#![doc(test(attr(..)))]everywhere)unsupported_calling_conventionslint to reject more invalid calling conventions #141435 (Add (back)unsupported_calling_conventionslint to reject more invalid calling conventions)Option<unsafe fn()>#141447 (Document representation ofOption<unsafe fn()>)const_eq_ignore_ascii_case#142065 (Stabilizeconst_eq_ignore_ascii_case)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup