Clarified doc comments + added tests confirming current behavior for intersperse/intersperse_with
This PR builds on top of rust-lang/rust#152855. I just added clarifying comments to `intersperse`/`intersperse_with` about its guarantees for fused iterators (and how behavior for non-fused iterators are subject to change). I also added in tests for non-fused iterators demonstrating its current behavior; fused iterators are already tested for in existing tests for `intersperse`/`intersperse_with`.
core: make atomic primitives type aliases of `Atomic<T>`
Tracking issue: https://github.com/rust-lang/rust/issues/130539
This makes `AtomicI32` and friends type aliases of `Atomic<T>` by encoding their alignment requirements via the use of an internal `Storage` associated type. This is also used to encode that `AtomicBool` store a `u8` internally.
Modulo the `Send`/`Sync` implementations, this PR does not move any trait implementations, methods or associated functions – I'll leave that for another PR.
style: Update doctests for `TryFrom<integer> for bool` and `From<bool> for float`
These doctests are attached to the `TryFrom` trait and the `From` trait. Although `From<U> for T` implies `Into<T> for U` and `TryFrom<U> for T` implies `TryInto<T> for U`, I think it is easier to understand to use the `try_from`/`from` method directly instead of the `try_into`/`into` method.
refactor 'valid for read/write' definition: exclude null
This is an attempt to resolve https://github.com/rust-lang/rust/issues/138351.
The underlying problem is that when we decided to allow reads/writes/copies of size 0 even for null pointers, we documented that by changing the definition of "valid for read/write" in the standard library to say that null pointers are valid for 0-sized reads/writes. Unfortunately, that definition is also used in other places that assume that a valid-for-read/write pointer can be converted into a reference, and of course that's UB if the pointer is null, even if the pointee is a ZST.
The proposal for fixing this is to make "valid for reads/writes" slightly [weaker](https://faultlore.com/blah/tower-of-weakenings/) than it has to be, and require the pointer to be non-null, and then to add exceptions to the most basic functions (read/write/copy) to explicitly allow arbitrary pointers when the size is 0. This isn't pretty but it's the best solution that has been suggested so far I think.
Cc @rust-lang/opsem @rust-lang/libs-api
add field representing types
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/152730)*
> [!NOTE]
> This is a rewrite of #146307 by using a lang item instead of a custom `TyKind`. We still need a `hir::TyKind::FieldOf` variant, because resolving the field name cannot be done before HIR construction. The advantage of doing it this way is that we don't need to make any changes to types after HIR (including symbol mangling). At the very beginning of this feature implementation, I tried to do it using a lang item, but then quickly abandoned the approach, because at that time I was still intending to support nested fields.
Here is a [range-diff](https://triagebot.infra.rust-lang.org/gh-range-diff/rust-lang/rust/605f49b27444a738ea4032cb77e3bdc4eb811bab..d15f5052095b3549111854a2555dd7026b0a729e/605f49b27444a738ea4032cb77e3bdc4eb811bab..f5f42d1e03495dbaa23671c46b15fccddeb3492f) between the two PRs
---
# Add Field Representing Types (FRTs)
This PR implements the first step of the field projection lang experiment (Tracking Issue: rust-lang/rust#145383). Field representing types (FRTs) are a new kind of type. They can be named through the use of the `field_of!` macro with the first argument being the type and the second the name of the field (or variant and field in the case of an enum). No nested fields are supported.
FRTs natively implement the `Field` trait that's also added in this PR. It exposes information about the field such as the type of the field, the type of the base (i.e. the type that contains the field) and the offset within that base type. Only fields of non-packed structs are supported, fields of enums an unions have unique types for each field, but those do not implement the `Field` trait.
This PR was created in collaboration with @dingxiangfei2009, it wouldn't have been possible without him, so huge thanks for mentoring me!
I updated my library solution for field projections to use the FRTs from `core` instead of creating my own using the hash of the name of the field. See the [Rust-for-Linux/field-projection `lang-experiment` branch](https://github.com/Rust-for-Linux/field-projection/tree/lang-experiment).
## API added to `core::field`
```rust
pub unsafe trait Field {
type Base;
type Type;
const OFFSET: usize;
}
pub macro field_of($Container:ty, $($fields:expr)+ $(,)?);
```
Along with a perma-unstable type that the compiler uses in the expansion of the macro:
```rust
#[unstable(feature = "field_representing_type_raw", issue = "none")]
pub struct FieldRepresentingType<T: ?Sized, const VARIANT: u32, const FIELD: u32> {
_phantom: PhantomData<T>,
}
```
## Explanation of Field Representing Types (FRTs)
FRTs are used for compile-time & trait-level reflection for fields of structs & tuples. Each struct & tuple has a unique compiler-generated type nameable through the `field_of!` macro. This type natively contains information about the field such as the outermost container, type of the field and its offset. Users may implement additional traits on these types in order to record custom information (for example a crate may define a [`PinnableField` trait](https://github.com/Rust-for-Linux/field-projection/blob/lang-experiment/src/marker.rs#L9-L23) that records whether the field is structurally pinned).
They are the foundation of field projections, a general operation that's generic over the fields of a struct. This genericism needs to be expressible in the trait system. FRTs make this possible, since an operation generic over fields can just be a function with a generic parameter `F: Field`.
> [!NOTE]
> The approach of field projections has changed considerably since this PR was opened. In the end we might not need FRTs, so this API is highly experimental.
FRTs should act as though they were defined as `struct MyStruct_my_field<StructGenerics>;` next to the struct. So it should be local to the crate defining the struct so that one can implement any trait for the FRT from that crate. The `Field` traits should be implemented by the compiler & populated with correct information (`unsafe` code needs to be able to rely on them being correct).
## TODOs
There are some `FIXME(FRTs)` scattered around the code:
- Diagnostics for `field_of!` can be improved
- `tests/ui/field_representing_types/nonexistent.rs`
- `tests/ui/field_representing_types/non-struct.rs`
- `tests/ui/field_representing_types/offset.rs`
- `tests/ui/field_representing_types/not-field-if-packed.rs`
- `tests/ui/field_representing_types/invalid.rs`
- Simple type alias already seem to work, but might need some extra work in `compiler/rustc_hir_analysis/src/hir_ty_lowering/mod.rs`
r? @oli-obk
These doctests are attached to the `TryFrom` trait. Therefore, it is
easier to understand to use the `try_from` method instead of the
`try_into` method.
Fix mem::conjure_zst panic message to use any::type_name instead
Use `crate::any::type_name::<T>()` instead of `stringify!(T)` in the
runtime panic message of `conjure_zst` , so the actual type name (e.g.
`i32`) is shown rather than the literal string `[T]`.
deprecate `Eq::assert_receiver_is_total_eq` and emit FCW on manual impls
The `Eq::assert_receiver_is_total_eq` method is purely meant as an implementation detail by `#[derive(Eq)]` to add checks that all fields of the type the derive is applied to also implement `Eq`.
The method is already `#[doc(hidden)]` and has a comment saying `// This should never be implemented by hand.`.
Unfortunately, it has been stable since 1.0 and there are some cases on GitHub (https://github.com/search?q=assert_receiver_is_total_eq&type=code) where people have implemented this method manually, sometimes even with actual code in the method body (example: https://github.com/Shresht7/codecrafters-redis-rust/blob/31f0ec453c504b4ab053a7b1c3ff548ff36a9db5/src/parser/resp/types.rs#L255).
To prevent further confusion from this, this PR is deprecating the method and adds a FCW when it is manually implemented (this is necessary as the deprecation warning is not emitted when the method is implemented, only when it is called).
This is similar to what was previously done with the `soft_unstable` lint (https://github.com/rust-lang/rust/issues/64266).
See also https://github.com/rust-lang/libs-team/issues/704.
ptr::replace: make calls on ZST null ptr not UB
See https://github.com/rust-lang/rust/issues/138351 for context.
We made `ptr::read` and `ptr::write` not UB on ZST null pointers. This does the same with `ptr::replace`. Since we're just adding a branch on a constant, this should come at no runtime cost.
Fixed ByteStr not padding within its Display trait when no specific alignment is mentioned
Fixesrust-lang/rust#152804. `Path`'s `Display` uses `ByteStr`'s `Display`, which is where the problem was occurring.
The issue was coming from `ByteStr` implementation of `fmt()` in this particular area:
```rust
let Some(align) = f.align() else {
return fmt_nopad(self, f);
};
let nchars: usize = self
.utf8_chunks()
.map(|chunk| {
chunk.valid().chars().count() + if chunk.invalid().is_empty() { 0 } else { 1 }
})
.sum();
let padding = f.width().unwrap_or(0).saturating_sub(nchars);
let fill = f.fill();
let (lpad, rpad) = match align {
fmt::Alignment::Left => (0, padding),
fmt::Alignment::Right => (padding, 0),
fmt::Alignment::Center => {
let half = padding / 2;
(half, half + padding % 2)
}
};
```
The docs for the align implies that `Alignment::Left`, `Alignment::Right`, `Alignment::Center` comes from `:<`, `:>`, and `:^` respectively with `align()` returning `None` if neither of those symbols are used in the formatted string. However, while padding is taken care of in the aligned cases, we could still have padding for things that don't use alignment like:
```rust
assert_eq!(format!("{:10}", Path::new("/foo/bar").display()), "/foo/bar ");
```
We shouldn't write to `f` and return from there when there's no alignment; we should also include any potential padding/filling bytes here.
r? @joboet
std::ops::ControlFlow - use normal comment for internal methods
Rather than a doc comment, which causes rustdoc to output the impl documentation even though the impl block only has non-public methods.
DOC: do not link to "nightly" in Iterator::by_ref() docstring
I happened to see that the link in the docstring https://doc.rust-lang.org/std/iter/trait.Iterator.html#method.by_ref points to the "nightly" docs instead of "stable".
I'm not sure if my fix actually works because I didn't get `cargo doc` to run on my local computer.
fix stale comments left over from ed3711e
Remove stale overflow comments in core::str.
Commit ed3711ea introduced stale comments in library/core/src/str/iter.rs.
Prior to that commit, the comments explained why `(len + 3)` and `(len + 2)` couldn't overflow.
Since the code now uses `div_ceil`, these specific overflow justifications are no longer relevant to the current implementation.
std::r#try! - avoid link to nightly docs
Use a relative link to the current version of rust-by-example rather than sending people to the nightly version.
Reflection TypeKind::FnPtr
This is for https://github.com/rust-lang/rust/issues/146922.
Const-eval currently lacks full support for function pointer (fn) types. We should implement handling of FnPtr TypeKind, covering safe and unsafe functions, Rust and custom ABIs, input and output types, higher-ranked lifetimes, and variadic functions.
- Implement handling of FnPtr TypeKind in const-eval, including:
- Unsafety flag (safe vs unsafe fn)
- ABI variants (Rust, Named(C), Named(custom))
- Input and output types
- Variadic function pointers
- Add const-eval tests covering:
- Basic Rust fn() pointers
- Unsafe fn() pointers
- Extern C and custom ABI pointers
- Functions with multiple inputs and output types
- Variadic functions
- Use const TypeId checks to verify correctness of inputs, outputs, and payloads
Jonathan Brouwer