I'm ignoring the fact that there's a feature to change the behavior of
the syntax. I just want to help prevent confusing the people reading
the docs.
(cherry picked from commit eef4363403)
I'm ignoring the fact that there's a feature to change the behavior of
the syntax. I just want to help prevent confusing the people reading
the docs.
(cherry picked from commit 092f0ca1bd)
This implementation was added recently in f12288ec26
("TryFrom<integer> for bool") but used an old feature gate and
stabilization version. Update to reflect when these were actually added.
(cherry picked from commit 02b516afd9)
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
carryless_mul: mention the base
Arithmetic operations do not typically care about the base that is used to represent numbers, but this one does. Mentioning that makes it easier to understand the operation, I think.
Cc @folkertdev
make `rustc_allow_const_fn_unstable` an actual `rustc_attrs` attribute
It is already named like one, but used to have its own feature gate, which this PR now removes in favor of just using `#![feature(rustc_attrs)]`.
Most of the diff is just the line number changes in `malformed-attrs.stderr`.
Add documentation note about signed overflow direction
In https://github.com/rust-lang/rust/issues/151989#issuecomment-3845282666 I noticed that signed overflow direction can be determined by returned wrapped value. It is not very obvious (especially, assuming additional `carry: bool` summand), but it is important if we want to add new leading (signed) limb to big integer in this case.
Examples for small summands `x, y: i8` with result extension:
| x | y | overflow | result as (u8, i8) |
| ---- | ---- | -------- | ------------------ |
| -1 | -128 | true | (127, -1) |
| 0 | -1 | false | (255, -1) |
| 2 | 2 | false | (4, 0) |
| 127 | 1 | true | (128, 0) |
Here is general proof.
1. Set $s=2^{N-1}$ and let's say `iN::carrying_add(x, y, c)` returns `(result, true)` then
$$
\mathrm{result}=\begin{cases}
x + y + c + 2s,& x + y + c \le -s-1,\\
x+y+c-2s,& x+y+c\ge s.
\end{cases}
$$
First case is overflowing below `iN::MIN` and we have
$$
\mathrm{result}\ge -s-s+0+2s =0;\qquad
\mathrm{result}=x + y + c + 2s\le -s-1+2s = s - 1,
$$
so we obtain $[0; s-1]$ which is exactly range of non-negative `iN`.
Second case is overflowing above `iN::MAX` and
$$
\mathrm{result}=x+y+c-2s\ge s-2s =-s;\qquad
\mathrm{result}\le s-1 + s-1+1-2s = -1,
$$
that is, $[-s,-1]$ which is exactly range of negative `iN`.
2. Now suppose that `iN::borrowing_sub(x,y,b)` returns `(result, true)` then
$$
\mathrm{result}=\begin{cases}
x - y - b + 2s,& x - y - b \le -s-1,\\
x - y - b - 2s,& x - y - b\ge s.
\end{cases}
$$
First case is overflowing below `iN::MIN` and we have
$$
\mathrm{result}\ge -s-(s-1)-1+2s =0;\qquad
\mathrm{result}=x - y - b + 2s\le -s-1+2s = s - 1.
$$
Second case is overflowing above `iN::MAX` and
$$
\mathrm{result}=x-y-b-2s\ge s-2s =-s;\qquad
\mathrm{result}\le s-1 - (-s) - 0 - 2s = -1.
$$
Jake Goulding