Rollup of 12 pull requests - #161874
Closed
matthiaskrgr wants to merge 29 commits into
Closed
Conversation
... and related machienery
Remove trivial bounds Panic on NaN Make assert messages consistent with field names Add clamp_to coretests Update to fmt style Use target_has_reliable_fN_math Change existing clamp tests to use reliable_math Use reliable_math on doctests too Add #[expect] for NaN check
This is the normal behavior on other targets, but previously on wasm the data segment would be in the default section and instead a custom section with the given name would be added to the wasm module.
…lt implementations
…v6 multicast_loop methods
…, where the name is ambiguous, make to always report the `ambiguous_glob_imported_traits` lint independent of the ordering of exports. Added a test to make sure both ordering trigger the lint.
Implement clamp_to Implements the revised version of rust-lang#147781. Supersedes rust-lang#147786. Currently I restrict the ClampBounds trait using a second, perma-unstable feature. I don't know if that's the usual way to deal with this kind of traits, I'd be happy to change it if not. ~~I currently define NaN as equal to no bound. This is consistent with `max` and `min`, but is inconsistent with `clamp`, which panics.~~ Changed so that the float versions panic if any bound is NaN, just like `clamp` does.
…ianqk Codegen Overloaded LLVM intrinsics based on their name This is a continuation of rust-lang#140763 - now codegenning overloaded LLVM intrinsics based on their name too. This PR parses the `link_name` of the LLVM intrinsics for the type parameters, partially inverting [`getMangledTypeStr`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00076) and [`getIntrinsicNameImpl`](https://llvm.org/doxygen/Intrinsics_8cpp_source.html#l00165) from LLVM. There is the concern that @nikic's work on LLVM intrinsics might remove the name mangling, but we can just retain that from the Rust side. I mean even though the LLVM IR wouldn't have the mangling, but we can require that the Rust `link_name` argument contain the mangling. This shouldn't break anything, as existing code already has the name mangling. There is also the concern that this cannot parse `TargetExt` types and non-literal struct types, as their mangling contains their name. If needed in future, we can maybe hardcode some known `TargetExt` types, but currently we don't support it. It also kinda helps that Rust currently cannot handle `TargetExt` types. The named struct one is not that big of a problem because courtesy of rust-lang#140763 we can already repack structs. I have not added support of LLVM `byte` type because it is only available in LLVM22, and we support min-LLVM version 20 afaik. I prefer this approach over the `IITDesc` approach highlighted in rust-lang#140763 because this approach allows code like ```rust #[link_name = "llvm.sqrt.v8bf16"] fn foo(a: u16x8) -> u16x8; ``` which pairs up with the autocasts of rust-lang#140763 to give a nice way to call overloaded intrinsics on `bf16`. Also this approach is a lot less work and more resilient to LLVM changes than the `IITDesc` approach. One important change - the parsing doesn't account for LLVM typed pointers, which were deprecated in LLVM15 and removed in LLVM17, so I didn't bother putting support for them. So, I also removed all uses of typed pointers from the tree. r? @dianqk as you might have more of a context on this due to reviewing the last 2 PRs cc @nikic
std: avoid aliasing violations when wrapping opaque C types Fixes rust-lang#160815 (and some other instances of the same problem) See the new documentation of `COpaque` for a detailed description of the kinds of issues solved by this. In short: creating mutable references to the opaque types from pthread is unsound since some platforms (at least AIX) store an intrinsically list of these types and the creation of the mutable reference (e.g. in the drop glue) invalidates the other pointers to the type. This doesn't just apply to the internal pthread `Condvar` and `Mutex` abstraction as described in the issue, but also to all other opaque types – nobody is promising us that these are not internally aliased. Hence this PR adds an internal `COpaque` helper type which uses a combination of `UnsafePinned` and `MaybeUninit` to relax all relevant requirements added by Rust's operational semantics. CC @RalfJung I'd love to hear your opinion on this r? libs
…ort-trait-lint, r=petrochenkov Prefer ambiguous candidates when deduplicating traits in scope, so `ambiguous_glob_imported_traits` doesn't depend on import order Fixes rust-lang#160742 When inserting candidates for a method pick we deduplicate candidates based on the trait id, this "deleted" traits that where (not) ambiguous: ```rust // depending on the order, the second one is removed mod prelude { pub use crate::expression::IntoSql; pub use crate::expression::IntoSql as _; } use module::*; // imports some item names IntoSql use prelude::*; // imports trait `IntoSql` and `IntoSql as _` ``` This caused the lint `ambiguous_glob_imported_traits` to not be triggered if the `as _` came first, even though both are actually in scope. We now deduplicate based on `(def_id, lint_ambiguous)` and later check that if an ambiguous candidate is present in `collapse_candidates_to_trait_pick`, we mark the pick as `lint_ambiguous`. (its also easy to reverse the behaviour of this change). Also added a test with 2 revisions placing the `as _` export first or last. It's the most "clean" way I could come up, hopefully someone more versed in this part of the compiler could tell me how it is done in a better way :). cc @petrochenkov, since I feel like you know if the lint should be triggered or not in this case. LLM disclosure: I used a LLM to create a shorter PR title, because i couldn't come up with a short one.
…ustom_section, r=alexcrichton Put data segment in specified section with link_section on wasm This is the normal behavior on other targets, but previously on wasm the data segment would be in the default section and instead a custom section with the given name would be added to the wasm module. Fixes rust-lang#146538 r? alexcrichton
…ault-functions, r=petrochenkov delegation: add tests fixating behavior of delegating to default trait implementations This PR adds tests for delegation to trait functions that have default implementation, thus fixating current behavior. Part of rust-lang#118212. r? @petrochenkov
Print vendor instructions in `x vendor` When the user manually runs `x vendor`, we should tell them what to put into their `.cargo/config.toml` file. This regressed some time ago when the Vendor step was refactored in bootstrap, I think. Before this PR, the part after "this project" was blank: ``` To use vendored sources, add this to your .cargo/config.toml for this project: [source.crates-io] replace-with = "vendored-sources" [source."git+https://github.com/rust-lang/team"] git = "https://github.com/rust-lang/team" replace-with = "vendored-sources" [source.vendored-sources] directory = "vendor" ``` r? bjorn3
Allow Unpin impls for local extern type Fixes rust-lang#155053 `visit_implementation_of_unpin` helper only handles `ty::Adt` and does delay the bug for everything else. The orphan check is what allows a local foreign type i.e. `ty::Foreign` and that's why we can each that arm and ICE. Discloure: Only the test comments were genarated using an LLM.
…-type-mismatch-attribution, r=folkertdev Improve type mismatch annotation for lets with block-wrapped initializers Fixes rust-lang#127048
…=JonathanBrouwer Never type after-stabilization cleanup r? @JonathanBrouwer
atomicptr.rs test: remove unused import
…pback, r=clarfonthey bind to [::1] instead of 127.0.0.1 in documentation examples for v6 UDP methods My first contribution towards rust-lang#161832 I think this is reasonable to do despite the ongoing discussion, as it's IPv6-specific methods and likely resulted from copy-pasting the code blocks.
rustbot
added
A-attributes
Member
Author
|
@bors r+ rollup=never p=5 |
Contributor
rust-bors
Bot
added
S-waiting-on-bors
Contributor
|
PR #157145, which is a member of this rollup, was unapproved. This rollup was thus unapproved. |
rustbot
removed
the
S-waiting-on-author
Collaborator
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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
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:
ambiguous_glob_imported_traitsdoesn't depend on import order #161805 (Prefer ambiguous candidates when deduplicating traits in scope, soambiguous_glob_imported_traitsdoesn't depend on import order)x vendor#161666 (Print vendor instructions inx vendor)r? @ghost
Create a similar rollup