don't suggest non-deriveable traits for unions
Fixesrust-lang/rust#137587
Before, the compiler suggested adding `#[derive(Debug)]` (other traits too) for unions,
which is misleading because some traits can't be automatically derived.
Only traits that are still suggested are Copy and Clone.
I noticed the error label changed after removing the suggestion. I hope this isn't a big deal, but let me know if that's an issue.
original example:
```rs
union Union {
member: usize,
}
impl PartialEq<u8> for Union {
fn eq(&self, rhs: &u8) -> bool {
unsafe { self.member == (*rhs).into() }
}
}
fn main() {
assert_eq!(Union { member: 0 }, 0);
}
```
before:
```
error[E0277]: `Union` doesn't implement `Debug`
--> src\main.rs:13:5
|
13 | assert_eq!(Union { member: 0 }, 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Debug` is not implemented for `Union`
|
= note: add `#[derive(Debug)]` to `Union` or manually `impl Debug for Union`
= note: this error originates in the macro `assert_eq` (in Nightly builds, run with -Z macro-backtrace for more info)
help: consider annotating `Union` with `#[derive(Debug)]`
|
2 + #[derive(Debug)]
3 | union Union {
|
```
after (the message doesn't suggest adding #[derive(Debug)] to unions)
```
error[E0277]: `Union` doesn't implement `Debug`
--> src\main.rs:13:5
|
13 | assert_eq!(Union { member: 0 }, 0);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ unsatisfied trait bound
|
help: the trait `Debug` is not implemented for `Union`
--> src\main.rs:2:1
|
2 | union Union {
| ^^^^^^^^^^^
= note: manually `impl Debug for Union`
```
two smaller feature cleanups
Remove an unneeded feature gate for a private macro and sort the used features correctly by whether they are language or library features.
Derive Macro Eq: link to more detailed documentation
Match the other derive macros in the module (Ord, PartialEq, PartialOrd) by linking to the section in the trait documentation about how the derive macro works.
Split the `dec2flt::RawFloat` trait for easier reuse
`RawFloat` is an internal trait with quite a few useful float properties. It currently resides in the `dec2flt` module but is also used in parsing, and would be nice to reuse other places. Unfortunately it cannot be implemented on `f128` because of limitations with how the parsing API is implemented (mantissa must fit into a u64).
To make the trait easier to work with, split it into the following:
* `Float`: Anything that is reasonably applicable to all floating point types.
* `FloatExt`: Items that should be part of `Float` but don't work for all float types. This will eventually be merged back into `Float` once it can be implemented on f128.
* `Lemire`: Items that are specific to the Lemire dec2flt algorithm.
These traits are then moved to places that make sense.
Builds on top of https://github.com/rust-lang/rust/pull/151900
Optimize 128-bit integer formatting
The compiler is unaware of the restricted range of the input, so it is unable to optimize out the final division and modulus. By doing this manually, we get a nontrivial performance gain.
r? @dtolnay
(copied from https://github.com/dtolnay/itoa/pull/68)
Add missing `track_caller` to overflowing trait methods
Fixesrust-lang/rust#152599 by adding `#[track_caller]` to arithmetic trait methods (`Neg`, `Shl`, `ShlAssign`, `Shr` and `ShrAssign`) so overflow panics report the correct call site instead of the trait definition.
The compiler is unaware of the restricted range of the input, so it is
unable to optimize out the final division and modulus. By doing this
manually, we get a nontrivial performance gain.
Remove string content from panics
String content can be useful for debugging panics, particularly when you are working on a small codebase where you can infer more about the path taken through your program based on the content of the string.
In production deployments that upload crashes for centralized debugging, string content poses a risk to user privacy. The string can accidentally contain information that the user is not expecting to share with the development team.
On balance it seems like the risks outweigh the benefits. It is easy to add a `dbg!()` statement to gather more information in development; but comparatively tricky to ensure panics are sanitized by every rust app that monitors their production deployments.
Ref https://internals.rust-lang.org/t/stop-including-string-content-in-index-panics/24067
r? @scottmcm
Add `From` impls for wrapper types
- ~`From<T: Copy> for ManuallyDrop<T>`~
- `From<T: UnwindSafe> for AssertUnwindSafe<T>`
- `From<T> for LazyCell<T, F>`
- `From<T> for LazyLock<T, F>`
- `From<T> for ThinBox<T>` (unstable)
- `From<T> for UniqueRc<T>` (unstable)
- `From<T> for UniqueArc<T>` (unstable)
@rustbot label T-libs-api needs-fcp
Also needs a crater run, as the insta-stable impls are technically breaking changes.
Gate `ConstParamTy_` trait behind `const_param_ty_trait` feature
Initially even when user wasn't using unsized const params, the only way to implement/name `ConstParamTy_` was to use `#![feature(unsized_const_params]`, now its gated under `const_param_ty_trait` feature, implied by `unsized_const_params`.
I've also changed use of `unsized_const_params` in tests which were using it only to implement `ConstParamTy_` without using unsized
r? BoxyUwU
Add overview documentation for `std::mem`.
I heard that `std::mem` sounds scary to some people, and how it’s described — “Basic functions for dealing with memory” — sounds even to me like something that should be avoided, not even because it would be unsafe, but because it is too low-level.
Let’s fix that by telling people about what they can actually find in the module, without having to read all the individual item descriptions.
The exact contents of the list are, of course, highly debatable, and I chose not to include any of the unstable or deprecated items, nor to include `Discriminant` as well as `discriminant`. I’m also not particularly happy with the wording of the introductory paragraph.
- `From<T> for ThinBox<T>`
- `From<T> for UniqueRc<T>`
- `From<T> for UniqueArc<T>`
- `From<T: UnwindSafe> for AssertUnwindSafe<T>`
- `From<T> for LazyCell<T, F>`
- `From<T> for LazyLock<T, F>`
`Float` and `FloatExt` are already used by both parsing and printing, so
move them out of `dec2flt` to a new module in `num::imp`. `Int` `Cast`
have the potential to be used more places in the future, so move them
there as well. `Lemire` is the only remaining trait; since it is small,
move it into the `dec2flt` root.
The `fmt::LowerExp` bound is removed from `Float` here since the trait
is moving into a module without `#[cfg(not(no_fp_fmt_parse))]` and it
isn't implemented with that config (it's not easily possible to add
`cfg` attributes to a single supertrait, unfortunately). This isn't a
problem since it isn't actually being used.
`RawFloat` is currently used specifically for the implementation of the
lemire algorithm, but it is useful for more than that. Split it into
three different traits:
* `Float`: Anything that is reasonably applicable to all floating point
types.
* `FloatExt`: Items that should be part of `Float` but don't work for
all float types. This will eventually be merged back into `Float`.
* `Lemire`: Items that are specific to the Lemire algorithm.
I heard that `std::mem` sounds scary to some people, and how it’s
described — “Basic functions for dealing with memory” — sounds even to
me like something that should be avoided, not even because it would be
unsafe, but because it is too low-level.
Let’s fix that by telling people about what they can actually find in
the module, without having to read all the individual item descriptions.
Fix grammar in Pin documentation
Changed "has an address-sensitive" to "has address-sensitive states" in the `Drop` implementation section of the documentation of `Pin` thereby making it grammatically complete.
core: remove FIXME comment in option.rs FromIterator
The referenced issue rust-lang/rust#11084 was closed in 2021, and the related PR rust-lang/rust#59605 was not merged due to inconclusive results. Similar code (in result.rs, for example) doesn't have this FIXME comment; this is the only reference to issue 11084 (or pull request 59605).
This FIXME was not mentioned in issue rust-lang/rust#44366.
Add missing safety doc for CString::from_vec_unchecked and async_drop_in_place
Add missing safety documentation for two unsafe APIs:
* `CString::from_vec_unchecked` – # Safety: the caller must ensure `v` contains no NUL bytes in its contents.
* `async_drop_in_place` – # Safety: see [`ptr::drop_in_place`] for safety requirements.
This FIXME is relevant not only to Option but other similar cases that
use iter::try_process(). The referenced issue 11084 was closed in 2021,
and the related PR 59605 was not merged due to inconclusive results.
Match the other derive macros in the module (Ord, PartialEq, PartialOrd) by
linking to the section in the trait documentation about how the derive macro
works.
Allow merging all libcore/alloc doctests into a single binary
This is only the changes needed to *allow* merging the tests. This doesn't actually turn doctest merging on in bootstrap. I think that might be a useful follow-up, since it makes them much faster to run, but it's not without downsides because it means we'll no longer be testing that doctests have all necessary `feature()` attributes.
The motivation for this change is to run the tests with `-C instrument-coverage` and then generate a coverage report from the output. Currently, this is very expensive because it requires parsing DWARF for each doctest binary. Merging the binaries decreases the time taken from several hours to ~30 seconds.
---
There are several parts to this change, most of which are independent and I'm happy to split out into other PRs.
- Upgrade process spawning logging from debug->info so it's easier to see, including in a rustdoc built without debug symbols.
- Core doctests now support being run with `-C panic=abort`. Ferrocene needs this downstream for complicated reasons; it's a one-line change so I figured it's not a big deal.
- Downgrade errors about duplicate features from a hard error to a warning. The meaning is clear here, and doctest merging often creates duplicate features since it lifts them all to the crate root. This involves changes to the compiler but generally I expect this to be low-impact.
- Enable this new warning, as well as several related feature lints, in rustdoc. By default rustdoc doesn't lint on anything except the lints it manually adds.
- Rustdoc now treats `allow(incomplete_features)` as a crate-level attribute, just like `internal_features`. Without this, it's possible to get hard errors if rustdoc lifts features to the crate level but not `allow`s.
- Core doctests now support being built with `--merge-doctests=yes`. In particular, I removed a few `$crate` usages and explicitly marked a few doctests as `standalone_crate`.
String content can be useful for debugging panics, particularly when you
are working on a small codebase where you can infer more about the path
taken through your program based on the content of the string.
In production deployments that upload crashes for centralized debugging,
string content poses a risk to user privacy. The string can accidentally
contain information that the user is not expecting to share with the
development team.
On balance it seems like the risks outweigh the benefits. It is easy to
add a `dbg!()` statement to gather more information in development; but
comparatively tricky to ensure panics are sanitized by every rust app
that monitors their production deployments.
Ref https://internals.rust-lang.org/t/stop-including-string-content-in-index-panics/24067
In `Option::get_or_insert_with()`, forget the `None` instead of dropping it.
Per https://github.com/rust-lang/rust/pull/148486#issuecomment-3493665688
In `Option::get_or_insert_with()`, after replacing the `None` with `Some`, forget the `None` instead of dropping it.
This allows eliminating the `T: [const] Destruct` bounds, making the functions more flexible in (unstable) const contexts, and avoids generating an implicit `drop_in_place::<Option<T>>()` that will never do anything (and which might even persist after optimization).
Unicode data: reduce size of to_lower/to_upper tables
Reduces the combined size of to_lower and to_upper from 25,364 bytes to 3,110 bytes. Explained in detail in the doc comments
core: respect precision in `ByteStr` `Display`
Fixesrust-lang/rust#153022.
`ByteStr`'s `Display` implementation didn't respect the precision parameter. Just like `Formatter::pad`, this is fixed by counting off the characters in the string and truncating after the requested length – with the added complication that the `ByteStr` needs to be divided into chunks first. By including a fast path that avoids counting the characters when no parameters were specified this should also fix the performance regressions caused by rust-lang/rust#152865.
Instead of generating a standalone executable to test `unicode_data`,
generate normal tests in `coretests`. This ensures tests are always
generated, and will be run as part of the normal testsuite.
Also change the generated tests to loop over lookup tables, rather than
generating a separate `assert_eq!()` statement for every codepoint. The
old approach produced a massive (20,000 lines plus) file which took
minutes to compile!
num: Separate public API from internal implementations
Currently we have a single `core::num` module that contains both thin wrapper API and higher-complexity numeric routines. Restructure this by moving implementation details to a new `imp` module.
This results in a more clean separation of what is actually user-facing compared to items that have a stability attribute because they are public for testing.
The first commit does the actual change then the second moves a portion back.
Update `UnsafeUnpin` impls involving extern types.
`UnsafeUnpin` tracking issue: https://github.com/rust-lang/rust/issues/125735
Relaxes from `T: ?Sized` (i.e. `T: MetaSized`) to `T: PointeeSized` for the `UnsafeUnpin` impls for pointers, references, and `PhantomData<T>`, and for the negative `UnsafeUnpin` impl for `UnsafePinned<T>`. (Compare to the impls for `Freeze` on lines 911-921.)
Both `UnsafeUnpin` and `extern type`s (the only way to have a `!MetaSized` type) are unstable, so this should have no effect on stable code.
Also updates the marker_impls macro docs to use PointeeSized bound, as most uses of the macro now do.
Concretely, this change means that the following types will newly implement `UnsafeUnpin`:
* pointers and references to `T` where `T` is an `extern type`
* `PhantomData<T>` where `T` is an extern type
* either of the above where `T` is a `struct` or tuple with `extern type` tail
Additionally, the negative `UnsafeUnpin` impl for `UnsafePinned<T>` is also relaxed to `T: PointeeSized` to align with the analogous negative `Freeze` impl for `UnsafeCell<T>`, even though both structs have `T: ?Sized` in their declaration (which probably should be relaxed, but that is a separate issue), so this part of the change doesn't actually *do* anything currently, but if `UnsafeCell` and `UnsafePinned` are later relaxed to `T: PointeeSized`, then the negative impl will apply to the newly possible instantiations. Also cc https://github.com/rust-lang/rust/issues/152645 that these impls compile at all.
Jonathan Brouwer