Rollup of 5 pull requests #135587
Merged
Rollup of 5 pull requests #135587
Conversation
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
…_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.
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. (Fixes rust-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`. (Fixes rust-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:`.
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=5 |
bors
added
S-waiting-on-bors
This comment was marked as off-topic.
This comment was marked as off-topic.
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: d8a64098c9 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
|
Finished benchmarking commit (8a6878a): comparison URL. Overall result: no relevant changes - no action needed@rustbot label: -perf-regression Instruction countThis benchmark run did not return any relevant results for this metric. Max RSS (memory usage)Results (primary -1.2%, secondary -0.1%)This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesThis benchmark run did not return any relevant results for this metric. Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 762.749s -> 763.031s (0.04%) |
# for free
to join this conversation on GitHub.
Already have an account?
# to comment
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)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup