Uh oh!
There was an error while loading. Please reload this page.
Rollup of 6 pull requests - #135584
Closed
matthiaskrgr wants to merge 19 commits into
Closed
Conversation
…_count','decrement_strong_count'
Apply eta-reduction on map to simplify code and make the style more consistent
Changes the behavior of the `overflowing_literals` suggestion so that it always suggest the smallest type regardless of the original type size.
The change between 0.1.143 and 0.1.144 includes refactoring that was in compiler-builtins before, but had to be reverted before landing in rust-lang/rust because the traits were leaking into diagnostics [1]. Recently a fix for this issue was merged [2] so the cleanup is reapplied here. This also acts as a regression test for [2]. [1]: rust-lang#128691 (comment) [2]: rust-lang#135278
Co-authored-by: Ibraheem Ahmed <ibraheem@ibraheem.ca>
…joshtriplett [cfg_match] Adjust syntax A year has passed since the creation of rust-lang#115585 and the feature, as expected, is not moving forward. Let's change that. This PR proposes changing the arm's syntax from `cfg(SOME_CONDITION) => { ... }` to `SOME_CODITION => {}`. ```rust match_cfg! { unix => { fn foo() { /* unix specific functionality */ } } target_pointer_width = "32" => { fn foo() { /* non-unix, 32-bit functionality */ } } _ => { fn foo() { /* fallback implementation */ } } } ``` Why? Because after several manual migrations in rust-lang#116342 it became clear, at least for me, that `cfg` prefixes are unnecessary, verbose and redundant. Again, everything is just a proposal to move things forward. If the shown syntax isn't ideal, feel free to close this PR or suggest other alternatives.
Update documentation for Arc::from_raw, Arc::increment_strong_count, and Arc::decrement_strong_count to clarify allocator requirement ### Related Issue: This update addresses parts of the issue raised in [rust-lang#134242](rust-lang#134242), where Arc's documentation lacks `Global Allocator` safety descriptions for three APIs. And this was confirmed by ``@workingjubilee`` : > Wait, nevermind. I apparently forgot the `increment_strong_count` is implicitly A = Global. Ugh. Another reason these things are hard to track, unfortunately. ### PR Description This PR updates the document for the following APIs: - `Arc::from_raw` - `Arc::increment_strong_count` - `Arc::decrement_strong_count` These APIs currently lack an important piece of documentation: **the raw pointer must point to a block of memory allocated by the global allocator**. This crucial detail is specified in the source code but is not reflected in the documentation, which could lead to confusion or incorrect usage by users. ### Problem: The following example demonstrates the potential confusion caused by the lack of documentation: ```rust #![feature(allocator_api)] use std::alloc::{Allocator,AllocError, Layout}; use std::ptr::NonNull; use std::sync::Arc; struct LocalAllocator { memory: NonNull<u8>, size: usize, } impl LocalAllocator { fn new(size: usize) -> Self { Self { memory: unsafe { NonNull::new_unchecked(&mut 0u8 as *mut u8) }, size, } } } unsafe impl Allocator for LocalAllocator { fn allocate(&self, _layout: Layout) -> Result<NonNull<[u8]>, AllocError> { Ok(NonNull::slice_from_raw_parts(self.memory, self.size)) } unsafe fn deallocate(&self, _ptr: NonNull<u8>, _layout: Layout) { } } fn main() { let allocator = LocalAllocator::new(64); let arc = Arc::new_in(5, &allocator); // Here, allocator could be any non-global allocator let ptr = Arc::into_raw(arc); unsafe { Arc::increment_strong_count(ptr); let arc = Arc::from_raw(ptr); assert_eq!(2, Arc::strong_count(&arc)); // Failed here! } } ```
…als-help, r=chenyukang Fix overflows in the implementation of `overflowing_literals` lint's help This PR fixes two overflow problems that cause the `overflowing_literals` lint to behave incorrectly in some edge cases. 1. When an integer literal is between `i128::MAX` and `u128::MAX`, an overflowing `as` cast can cause the suggested type to be overly small. It's fixed by using checked type conversion and returning `u128` when it's the only choice. (Fixesrust-lang#135248) 2. When an integer literal is `i128::MIN` but is of a smaller type, an overflowing negation cause the compiler to panic in debug build. Fixed by checking the number size beforehand and `wrapping_neg`. (Fixesrust-lang#131849) Edit: extracted the type conversion part into a standalone function to separate the concern of overflowing.
Only treat plain literal patterns as short See rust-lang#134228 (comment) and rust-lang#134228 (comment) for context. We never wanted to treat const blocks and paths as short, only plain literals. I don't know how to write a test for this, it.s not clear to me how the short pattern check actually affects the formatting
Clarify note in `std::sync::LazyLock` example I doubt most people know what it means, as I did not until a week ago. In the current form, it seems like a `TODO:`.
Update `compiler-builtins` to 0.1.144 The change between 0.1.143 and 0.1.144 includes refactoring that was in compiler-builtins before, but had to be reverted before landing in rust-lang/rust because the traits were leaking into diagnostics [1]. Recently a fix for this issue was merged [2] so the cleanup is reapplied here. This also acts as a regression test for [2]. [1]: rust-lang#128691 (comment) [2]: rust-lang#135278
matthiaskrgr
commented
Jan 16, 2025
MemberAuthor
@bors r+ rollup=never p=6 |
bors
commented
Jan 16, 2025
Collaborator
fmease
commented
Jan 16, 2025
Member
I'm pretty sure this will fail again due to #135560 |
fmease
commented
Jan 16, 2025
Member
Also, bors is stuck? |
bors
commented
Jan 16, 2025
Collaborator
bors added a commit
to rust-lang-ci/rust
that referenced
this pull request
Jan 16, 2025
…iaskrgr Rollup of 6 pull requests Successful merges: - rust-lang#133720 ([cfg_match] Adjust syntax) - rust-lang#134496 (Update documentation for Arc::from_raw, Arc::increment_strong_count, and Arc::decrement_strong_count to clarify allocator requirement) - rust-lang#135249 (Fix overflows in the implementation of `overflowing_literals` lint's help) - rust-lang#135251 (Only treat plain literal patterns as short) - rust-lang#135556 (Clarify note in `std::sync::LazyLock` example) - rust-lang#135560 (Update `compiler-builtins` to 0.1.144) r? `@ghost` `@rustbot` modify labels: rollup
matthiaskrgr
commented
Jan 16, 2025
MemberAuthor
yeet |
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
9 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:
overflowing_literalslint's help #135249 (Fix overflows in the implementation ofoverflowing_literalslint's help)std::sync::LazyLockexample #135556 (Clarify note instd::sync::LazyLockexample)compiler-builtinsto 0.1.144 #135560 (Updatecompiler-builtinsto 0.1.144)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup