Rollup of 8 pull requests #120162
Closed
Rollup of 8 pull requests #120162
Conversation
This file contains 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
Currently stable users can't benefit from this because GlobaAlloc doesn't support alignment-changing realloc and neither do most posix allocators. So in practice it always results in an extra memcpy.
InPlaceDstBufDrop holds onto the allocation before the shrinking happens which means it must deallocate the destination elements but the source allocation.
…e impl is implemented on a type alias
…u-se Implement strict integer operations that panic on overflow This PR implements the first part of the ACP for adding panic on overflow style arithmetic operations (rust-lang/libs-team#270), mentioned in rust-lang#116064. It adds the following operations on both signed and unsigned integers: - `strict_add` - `strict_sub` - `strict_mul` - `strict_div` - `strict_div_euclid` - `strict_rem` - `strict_rem_euclid` - `strict_neg` - `strict_shl` - `strict_shr` - `strict_pow` Additionally, signed integers have: - `strict_add_unsigned` - `strict_sub_unsigned` - `strict_abs` And unsigned integers have: - `strict_add_signed` The `div` and `rem` operations are the same as normal division and remainder but are added for completeness similar to the corresponding `wrapping_*` operations. I'm not sure if I missed any operations, I basically found them from the `wrapping_*` and `checked_*` operations on both integer types.
Make traits / trait methods detected by the dead code lint Fixes rust-lang#118139 and rust-lang#41883
…n-ty-alias, r=notriddle Fix impl stripped in rustdoc HTML whereas it should not be in case the impl is implemented on a type alias Fixes rust-lang#119015. I talked about it a bit with `@petrochenkov.` They might change what `EffectiveVisibilities` return for impl items like this one and make them not only reachable but also re-exported, which would fix this case. It could also potentially break other things, so it'll be done whenever they can and then we can check together. Surprisingly, this fix is making rustdoc even closer to rustc in term of errors (the CI currently fails because currently accepted broken codes aren't working anymore with this change). Not sure exactly why though. This is linked to rust-lang#110631 from what I could find. So either I'm missing something here, or we consider it's ok and we consider the failing tests as "should fail" and I'll update `rustdoc-ui` ones. r? `@notriddle`
…compiler-errors pattern_analysis: Remove `Ty: Copy` bound To make it compatible with rust-analyzer's `Ty` which isn't `Copy` (it's an `Arc`). r? `@compiler-errors`
…=compiler-errors Make generic const type mismatches not hide trait impls from the trait solver pulled out of rust-lang#119895 It does improve diagnostics somewhat, but also causes some extraneous diagnostics in potentially misleading order. The issue was that a const type mismatch, instead of reporting an error, would silently poison the constant, only for that information to be thrown away and the impl to be treated as "not matching". In rust-lang#119895 this would cause ICEs as well as errors on impls stating that the impl needs to exist for itself to be valid.
…viper Remove alignment-changing in-place collect This removes the alignment-changing in-place collect optimization introduced in rust-lang#110353 Currently stable users can't benefit from the optimization because GlobaAlloc doesn't support alignment-changing realloc and neither do most posix allocators. So in practice it has a negative impact on performance. Explanation from rust-lang#120091 (comment): > > You mention that in case of alignment mismatch -- when the new alignment is less than the old -- the implementation calls `mremap`. > > I was trying to note that this isn't really the case in practice, due to the semantics of Rust's allocator APIs. The only use of the allocator within the `in_place_collect` implementation itself is [a call to `Allocator::shrink()`](https://github.com/rust-lang/rust/blob/db7125f008cfd72e8951c9a863178956e2cbacc3/library/alloc/src/vec/in_place_collect.rs#L299-L303), which per its documentation [allows decreasing the required alignment](https://doc.rust-lang.org/1.75.0/core/alloc/trait.Allocator.html). However, in stable Rust, the only available `Allocator` is [`Global`](https://doc.rust-lang.org/1.75.0/alloc/alloc/struct.Global.html), which delegates to the registered `GlobalAlloc`. Since `GlobalAlloc::realloc()` [cannot change the required alignment](https://doc.rust-lang.org/1.75.0/core/alloc/trait.GlobalAlloc.html#method.realloc), the implementation of [`<Global as Allocator>::shrink()`](https://github.com/rust-lang/rust/blob/db7125f008cfd72e8951c9a863178956e2cbacc3/library/alloc/src/alloc.rs#L280-L321) must fall back to creating a brand-new allocation, `memcpy`ing the data into it, and freeing the old allocation, whenever the alignment doesn't remain exactly the same. > > Therefore, the underlying allocator, provided by libc or some other source, has no opportunity to internally `mremap()` the data when the alignment is changed, since it has no way of knowing that the allocation is the same.
…albertlarsan68 Increase vscode settings.json `git.detectSubmodulesLimit` The default vscode git integration throws a warning on the rust repository because it has more than the default limit of 10 submodules. This adds an increase to 20 to the settings.json that x.py offers to install on setup. <img width="461" alt="Screen Shot 2024-01-19 at 11 47 47 PM" src="https://github.com/rust-lang/rust/assets/230691/440dfa4e-32e3-41f7-b8c6-5a07ade7aa14"> Also reported at https://stackoverflow.com/questions/60917209/disable-vs-code-warning-submodules-which-wont-be-opened-automatically
…uviper fix: Drop guard was deallocating with the incorrect size InPlaceDstBufDrop holds onto the allocation before the shrinking happens which means it must deallocate the destination elements but the source allocation. Thanks `@cuviper` for spotting this.
rustbot
added
A-testsuite
|
@bors r+ p=5 rollup=never |
bors
added
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
@bors r- |
bors
added
S-waiting-on-author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in 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:
Ty: Copybound #120027 (pattern_analysis: RemoveTy: Copybound)git.detectSubmodulesLimit#120138 (Increase vscode settings.jsongit.detectSubmodulesLimit)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup