| Age | Commit message (Collapse) | Author | Lines |
|---|
|
NaN and infinity are not included as they require arithmetic.
|
|
Document never type fallback in `!`'s docs
Pulled the documentation I've written for #123939.
I want a single place where never type fallback is explained, which can be referred in all the lints and migration materials.
|
|
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
|
|
|
|
|
|
|
|
Co-authored-by: Kevin Reid <kpreid@switchb.org>
Co-authored-by: Herman Skogseth <herman.skogseth@me.com>
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
|
|
|
|
|
|
Add diagnostic item for `std::iter::Iterator::enumerate`
Adds a diagnostic item for the `std::iter:Iterator::enumerate` trait method. This change, along with PR https://github.com/rust-lang/rust/pull/124308, will be used by the clippy `unused_enumerate_index` lint to move away from paths to using diagnostic items.
see: https://github.com/rust-lang/rust-clippy/issues/5393
|
|
Use `target_vendor = "apple"` instead of `target_os = "..."`
Use `target_vendor = "apple"` instead of `all(target_os = "macos", target_os = "ios", target_os = "tvos", target_os = "watchos", target_os = "visionos")`.
The apple targets are quite close to being identical, with iOS, tvOS, watchOS and visionOS being even closer, so using `target_vendor` when possible makes it clearer when something is actually OS-specific, or just Apple-specific.
Note that `target_vendor` will [be deprecated in the future](https://github.com/rust-lang/rust/issues/100343), but not before an alternative (like `target_family = "apple"`) is available.
While doing this, I found various inconsistencies and small mistakes in the standard library, see the commits for details. Will follow-up with an extra PR for a similar issue that need a bit more discussion. EDIT: https://github.com/rust-lang/rust/pull/124494
Since you've talked about using `target_vendor = "apple"` in the past:
r? workingjubilee
CC `@simlay,` `@thomcc`
`@rustbot` label O-macos O-ios O-tvos O-watchos O-visionos
|
|
|
|
Fix #124478 - offset_of! returns a temporary
This was due to the must_use() call. Adding HIR's `OffsetOf` to the must_use checking within the compiler avoids this issue while maintaining the lint output.
Fixes #124478. `@tgross35`
|
|
Update `is_val_statically_known` Docs
* Add `Type Requirements` section, listing the allowed inputs, as requested by #121115
* Add `Pointers` subsection, explaining is_val_statically_known handles pointers.
* Add `Stability concerns` section, referring to other documentation relating to consistency in `const` functions.
Fixes #121115
Sorry this took so long.
|
|
* Add `Type Requirements` section, listing the allowed inputs, as requested by #121115
* Add `Pointers` subsection, explaining is_val_statically_known handles pointers.
* Add `Stability concerns` section, referring to other documentation relating to consistency in `const` functions.
|
|
Fully stabilize the following API, including const where applicable:
impl <T> NonNull<T> {
pub const unsafe fn offset(self, count: isize) -> Self;
pub const unsafe fn add(self, count: usize) -> Self;
pub const unsafe fn sub(self, count: usize) -> Self;
pub const unsafe fn offset_from(self, origin: NonNull<T>) -> isize;
pub const unsafe fn read(self) -> T;
pub unsafe fn read_volatile(self) -> T;
pub const unsafe fn read_unaligned(self) -> T;
pub unsafe fn write_volatile(self, val: T);
pub unsafe fn replace(self, src: T) -> T;
}
impl<T: ?Sized> NonNull<T> {
pub const unsafe fn byte_offset(self, count: isize) -> Self;
pub const unsafe fn byte_add(self, count: usize) -> Self;
pub const unsafe fn byte_sub(self, count: usize) -> Self;
pub const unsafe fn byte_offset_from<U: ?Sized>(self, origin: NonNull<U>) -> isize;
pub unsafe fn drop_in_place(self);
}
Stabilize the following without const:
impl <T> NonNull<T> {
// const under `const_intrinsic_copy`
pub const unsafe fn copy_to(self, dest: NonNull<T>, count: usize);
pub const unsafe fn copy_to_nonoverlapping(self, dest: NonNull<T>, count: usize);
pub const unsafe fn copy_from(self, src: NonNull<T>, count: usize);
pub const unsafe fn copy_from_nonoverlapping(self, src: NonNull<T>, count: usize);
// const under `const_ptr_write`
pub const unsafe fn write(self, val: T);
pub const unsafe fn write_bytes(self, val: u8, count: usize);
pub const unsafe fn write_unaligned(self, val: T);
// const under `const_swap`
pub const unsafe fn swap(self, with: NonNull<T>);
// const under `const_align_offset`
pub const fn align_offset(self, align: usize) -> usize;
// const under `const_pointer_is_aligned`
pub const fn is_aligned(self) -> bool;
}
Left the following unstable:
impl <T> NonNull<T> {
// moved gate to `ptr_sub_ptr`
pub const unsafe fn sub_ptr(self, subtracted: NonNull<T>) -> usize;
}
impl <T: ?Sized> NonNull<T> {
// moved gate to `pointer_is_aligned_to`
pub const fn is_aligned_to(self, align: usize) -> bool;
}
Fixes: https://github.com/rust-lang/rust/issues/117691
|
|
|
|
This was due to the must_use() call. Adding HIR's OffsetOf to the must_use
checking within the compiler avoids this issue.
|
|
Abort a process when FD ownership is violated
When an owned FD has already been closed before it's dropped that means something else touched an FD in ways it is not allowed to. At that point things can already be arbitrarily bad, e.g. clobbered mmaps. Recovery is not possible.
All we can do is hasten the fire.
Unlike the previous attempt in #124130 this shouldn't suffer from the possibility that FUSE filesystems can return arbitrary errors.
|
|
Co-authored-by: Jubilee <46493976+workingjubilee@users.noreply.github.com>
|
|
|
|
|
|
|
|
|
|
Stabilize `Utf8Chunks`
Pending FCP in https://github.com/rust-lang/rust/issues/99543.
This PR includes the proposed modification in https://github.com/rust-lang/libs-team/issues/190 as agreed in https://github.com/rust-lang/rust/issues/99543#issuecomment-2050406568.
|
|
Convert some iter macros to normal functions
With all the MIR optimization changes that have happened since these were written, let's see if they still actually matter.
\*perf comes back\*
Well, it looks like it's not longer relevant for instruction, cycle, nor wall-time perf. Looks like a bunch of things are maybe 10kb bigger in debug, but some are also 50k *smaller* in debug.
So I think they should switch to being normal functions as the "greatly improves performance" justification for them being macros seems to no longer be true -- probably thanks to us always building `core` with `-Z inline-mir` so the difference is negligible.
|
|
With all the MIR optimization changes that have happened since these were written, let's see if they still actually matter.
|
|
|
|
|
|
chore: fix some typos in comments
|
|
Rollup of 6 pull requests
Successful merges:
- #123316 (Test `#[unix_sigpipe = "inherit"]` with both `SIG_DFL` and `SIG_IGN`)
- #123794 (More DefineOpaqueTypes::Yes)
- #123881 (Bump Fuchsia versions)
- #124281 (fix weak memory bug in TLS on Windows)
- #124282 (windows fill_utf16_buf: explain the expected return value)
- #124308 (Add diagnostic item for `std::iter::Enumerate`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
|
|
|
|
|
Add diagnostic item for `std::iter::Enumerate`
This adds a diagnostic item for `std::iter::Enumerate`. The change will be used by the clippy `unused_enumerate_index` lint to move away from type paths to using diagnostic items.
see: https://github.com/rust-lang/rust-clippy/issues/5393
|
|
And suggest adding the `#[coroutine]` to the closure
|
|
Signed-off-by: whosehang <whosehang@outlook.com>
|
|
|
|
Rollup of 3 pull requests
Successful merges:
- #124003 (Dellvmize some intrinsics (use `u32` instead of `Self` in some integer intrinsics))
- #124169 (Don't fatal when calling `expect_one_of` when recovering arg in `parse_seq`)
- #124286 (Subtree sync for rustc_codegen_cranelift)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Dellvmize some intrinsics (use `u32` instead of `Self` in some integer intrinsics)
This implements https://github.com/rust-lang/compiler-team/issues/693 minus what was implemented in #123226.
Note: I decided to _not_ change `shl`/... builder methods, as it just doesn't seem worth it.
r? ``@scottmcm``
|
|
alloc::Layout: explicitly document size invariant on the type level
https://github.com/rust-lang/rust/pull/95295 added this to the constructor, but it seems worth documenting the type invariant at the type level.
|
|
|
|
panic_str only exists for the migration to 2021 panic macros
The only caller is `expect_failed`, which is already a cold inline(never) function, so inlining into that function should be fine. (And indeed `panic_str` was `#[inline]` anyway.)
The existence of panic_str risks someone calling it when they should call `panic` instead, and I can't see a reason why this footgun should exist.
I also extended the comment in `panic` to explain why it needs a `'static` string -- I know I've wondered about this in the past and it took me quite a while to understand.
|
|
Add simple async drop glue generation
This is a prototype of the async drop glue generation for some simple types. Async drop glue is intended to behave very similar to the regular drop glue except for being asynchronous. Currently it does not execute synchronous drops but only calls user implementations of `AsyncDrop::async_drop` associative function and awaits the returned future. It is not complete as it only recurses into arrays, slices, tuples, and structs and does not have same sensible restrictions as the old `Drop` trait implementation like having the same bounds as the type definition, while code assumes their existence (requires a future work).
This current design uses a workaround as it does not create any custom async destructor state machine types for ADTs, but instead uses types defined in the std library called future combinators (deferred_async_drop, chain, ready_unit).
Also I recommend reading my [explainer](https://zetanumbers.github.io/book/async-drop-design.html).
This is a part of the [MCP: Low level components for async drop](https://github.com/rust-lang/compiler-team/issues/727) work.
Feature completeness:
- [x] `AsyncDrop` trait
- [ ] `async_drop_in_place_raw`/async drop glue generation support for
- [x] Trivially destructible types (integers, bools, floats, string slices, pointers, references, etc.)
- [x] Arrays and slices (array pointer is unsized into slice pointer)
- [x] ADTs (enums, structs, unions)
- [x] tuple-like types (tuples, closures)
- [ ] Dynamic types (`dyn Trait`, see explainer's [proposed design](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#async-drop-glue-for-dyn-trait))
- [ ] coroutines (https://github.com/rust-lang/rust/pull/123948)
- [x] Async drop glue includes sync drop glue code
- [x] Cleanup branch generation for `async_drop_in_place_raw`
- [ ] Union rejects non-trivially async destructible fields
- [ ] `AsyncDrop` implementation requires same bounds as type definition
- [ ] Skip trivially destructible fields (optimization)
- [ ] New [`TyKind::AdtAsyncDestructor`](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#adt-async-destructor-types) and get rid of combinators
- [ ] [Synchronously undroppable types](https://github.com/zetanumbers/posts/blob/main/async-drop-design.md#exclusively-async-drop)
- [ ] Automatic async drop at the end of the scope in async context
|
|
Stabilize generic `NonZero`.
Tracking issue: https://github.com/rust-lang/rust/issues/120257
r? `@dtolnay`
|
|
checked_ilog: improve performance
Addresses #115874.
(This PR replicates the original #115875, which I accidentally closed by deleting my forked repository...)
|
|
|
|
|
|
|
|
|
