Rollup of 12 pull requests #120401
Merged
Rollup of 12 pull requests #120401
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
The internal, unstable field of `Pin` can conflict with fields from the inner type accessed via the `Deref` impl. Rename it from `pointer` to `__pointer`, to make it less likely to conflict with anything else.
Introduce `From<core::ascii::char>` implementations for all unsigned numeric types and `char`. This matches the API of `char` type. Issue: rust-lang#110998
Co-authored-by: Wesley Wiser <wwiser@gmail.com>
…, r=dtolnay stabilise array methods Closes rust-lang#76118 Stabilises the remaining array methods FCP is yet to be carried out for this There wasn't a clear consensus on the naming, but all the other alternatives had some flaws as discussed in the tracking issue and there was a silence on this issue for a year
impl `From<&[T; N]>` for `Cow<[T]>`
Implement `From<&[T; N]>` for `Cow<[T]>` to simplify its usage in the following example.
```rust
fn foo(data: impl Into<Cow<'static, [&'static str]>>) { /* ... */ }
fn main() {
foo(vec!["hello", "world"]);
foo(&["hello", "world"]); // Error: the trait `From<&[&str; 2]>` is not implemented for `Cow<'static, [&'static str]>`
foo(&["hello", "world"] as &[_]); // Explicit convertion into a slice is required
}
```
Emit suggestion when trying to write exclusive ranges as `..<` Closes rust-lang#112254
…, r=Amanieu,dtolnay
Rename `pointer` field on `Pin`
A few days ago, I was helping another user create a self-referential type using `PhantomPinned`. However, I noticed an odd behavior when I tried to access one of the type's fields via `Pin`'s `Deref` impl:
```rust
use std::{marker::PhantomPinned, ptr};
struct Pinned {
data: i32,
pointer: *const i32,
_pin: PhantomPinned,
}
fn main() {
let mut b = Box::pin(Pinned {
data: 42,
pointer: ptr::null(),
_pin: PhantomPinned,
});
{
let pinned = unsafe { b.as_mut().get_unchecked_mut() };
pinned.pointer = &pinned.data;
}
println!("{}", unsafe { *b.pointer });
}
```
```rust
error[E0658]: use of unstable library feature 'unsafe_pin_internals'
--> <source>:19:30
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^
error[E0277]: `Pinned` doesn't implement `std::fmt::Display`
--> <source>:19:20
|
19 | println!("{}", unsafe { *b.pointer });
| ^^^^^^^^^^^^^^^^^^^^^ `Pinned` cannot be formatted with the default formatter
|
= help: the trait `std::fmt::Display` is not implemented for `Pinned`
= note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead
= note: this error originates in the macro `$crate::format_args_nl` which comes from the expansion of the macro `println` (in Nightly builds, run with -Z macro-backtrace for more info)
```
Since the user named their field `pointer`, it conflicts with the `pointer` field on `Pin`, which is public but unstable since Rust 1.60.0 with rust-lang#93176. On versions from 1.33.0 to 1.59.0, where the field on `Pin` is private, this program compiles and prints `42` as expected.
To avoid this confusing behavior, this PR renames `pointer` to `__pointer`, so that it's less likely to conflict with a `pointer` field on the underlying type, as accessed through the `Deref` impl. This is technically a breaking change for anyone who names their field `__pointer` on the inner type; if this is undesirable, it could be renamed to something more longwinded. It's also a nightly breaking change for any external users of `unsafe_pin_internals`.
Document `rustc_index::vec::IndexVec` Document a few of the methods. Part of rust-lang#93792.
…risDenton std: make `HEAP` initializer never inline The system allocator for Windows calls `init_or_get_process_heap` every time allocating. It generates very much useless code and makes the binary larger. The `HEAP` only needs to initialize once before the main fn. Concerns: * I'm not sure if `init` will be properly called in cdylib. * Do we need to ensure the allocator works if the user enables `no_main`? * Should we panic if `GetProcessHeap` returns null?
…alidating, r=oli-obk Normalize field types before checking validity I forgot to normalize field types when checking ADT-like aggregates in the MIR validator. This normalization is needed due to a crude check for opaque types in `mir_assign_valid_types` which prevents opaque type cycles -- if we pass in an unnormalized type, we may not detect that the destination type is an opaque, and therefore will call `type_of(opaque)` later on, which causes a cycle error -> ICE. Fixes rust-lang#120253
core: add `From<core::ascii::Char>` implementations Introduce `From<core::ascii::Char>` implementations for all unsigned numeric types and `char`. This matches the API of `char` type. Issue: rust-lang#110998
…r=cuviper mark a doctest with UB as no_run rust-lang#119911 added a doctest with UB. That one shouldn't be run, or else Miri will complain.
always normalize `LoweredTy` in the new solver I currently expect us to stop using alias bound candidates of normalizable aliases due to rust-lang/trait-system-refactor-initiative#77 by landing rust-lang#119744. At this point it mostly doesn't matter whether we eagerly normalize (and replace with infer vars in case of ambiguity). cc rust-lang#113473 previous attempt The infer var replacement for ambiguous projections can in very rare cases: - weaken inference rust-lang/trait-system-refactor-initiative#81 - strengthen inference rust-lang/trait-system-refactor-initiative#7 I do not expect this impact on inference to significantly affect real crates. r? ``@compiler-errors``
…-argument, r=Nadrieril Classify closure arguments in refutable pattern in argument error You can call it a function (and people may or may not agree with that), but it's better to just say those are closure arguments instead.
…tion, r=petrochenkov Add fmease to the compiler review rotation Following the call :) r? compiler
rustbot
added
A-meta
|
@bors r+ rollup=never p=12 |
bors
added
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
📌 Perf builds for each rolled up PR:
previous master: c073f56a41 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
This was referenced Jan 27, 2024
|
Finished benchmarking commit (b362939): comparison URL. Overall result: ❌✅ regressions and improvements - ACTION NEEDEDNext Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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.
CyclesResultsThis 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.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 659.743s -> 660.976s (0.19%) |
|
@rust-timer build 80930c3 |
This comment has been minimized.
This comment has been minimized.
|
Finished benchmarking commit (80930c3): comparison URL. Overall result: ✅ improvements - no action neededInstruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis 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: 659.743s -> 663.277s (0.54%) |
# 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:
From<&[T; N]>forCow<[T]>#113489 (implFrom<&[T; N]>forCow<[T]>)..<#119342 (Emit suggestion when trying to write exclusive ranges as..<)pointerfield onPin#119562 (Renamepointerfield onPin)rustc_index::vec::IndexVec#119800 (Documentrustc_index::vec::IndexVec)HEAPinitializer never inline #120205 (std: makeHEAPinitializer never inline)From<core::ascii::Char>implementations #120311 (core: addFrom<core::ascii::Char>implementations)LoweredTyin the new solver #120378 (always normalizeLoweredTyin the new solver)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup