use `is_multiple_of` and `div_ceil`
In tricky logic, these functions are much more informative than the manual implementations. They also catch subtle bugs:
- the manual `is_multiple_of` often does not handle division by zero
- manual `div_ceil` often does not consider overflow
The transformation is free for `is_multiple_of` if the divisor is compile-time known to be non-zero. For `div_ceil` there is a small cost to considering overflow. Here is some assembly https://godbolt.org/z/5zP8KaE1d.
move `va_copy`, `va_arg` and `va_end` to `core::intrinsics`
some questions:
- should these functions be `pub`?
- is a separate module justified?
r? `@RalfJung`
remove redundant #[must_use]
Fixes these clippy warnings:
```
warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
--> library/core/src/cmp.rs:1456:5
|
1456 | fn __chaining_lt(&self, other: &Rhs) -> ControlFlow<bool> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: either add some descriptive message or remove the attribute
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_must_use
= note: `-D clippy::double-must-use` implied by `-D warnings`
= help: to override `-D warnings` add `#[allow(clippy::double_must_use)]`
warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
--> library/core/src/cmp.rs:1465:5
|
1465 | fn __chaining_le(&self, other: &Rhs) -> ControlFlow<bool> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: either add some descriptive message or remove the attribute
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_must_use
warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
--> library/core/src/cmp.rs:1474:5
|
1474 | fn __chaining_gt(&self, other: &Rhs) -> ControlFlow<bool> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: either add some descriptive message or remove the attribute
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_must_use
warning: this function has a `#[must_use]` attribute with no message, but returns a type already marked as `#[must_use]`
--> library/core/src/cmp.rs:1483:5
|
1483 | fn __chaining_ge(&self, other: &Rhs) -> ControlFlow<bool> {
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= help: either add some descriptive message or remove the attribute
= help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#double_must_use
```
use unsigned_abs instead of `abs` on signed int to silence clippy
Use `unsigned_abs` instead of `abs` on signed int to silence clippy. Alternatively we could allow the lint, but if codegen is not affected, then this seems preferable.
minicore: use core's `diagnostic::on_unimplemented` messages
Without these attributes, the error message is different. Keeping the diagnostics up-to-date seems related to https://github.com/rust-lang/rust/issues/137531.
The modified test files are reported in https://github.com/rust-lang/rust/issues/143319 as failing for `--target=riscv64gc-unknown-linux-gnu`. Using `minicore` for them makes it easier to troubleshoot this sort of issue.
r? ``@jieyouxu``
setup typos check in CI
This allows to check typos in CI, currently for compiler only (to reduce commit size with fixes). With current setup, exclude list is quite short, so it worth trying?
Also includes commits with actual typo fixes.
MCP: https://github.com/rust-lang/compiler-team/issues/817
typos check currently turned for:
* ./compiler
* ./library
* ./src/bootstrap
* ./src/librustdoc
After merging, PRs which enables checks for other crates (tools) can be implemented too.
Found typos will **not break** other jobs immediately: (tests, building compiler for perf run). Job will be marked as red on completion in ~ 20 secs, so you will not forget to fix it whenever you want, before merging pr.
Check typos: `python x.py test tidy --extra-checks=spellcheck`
Apply typo fixes: `python x.py test tidy --extra-checks=spellcheck:fix` (in case if there only 1 suggestion of each typo)
Current fail in this pr is expected and shows how typo errors emitted. Commit with error will be removed after r+.
miri: improve errors for type validity assertion failures
Miri has pretty nice errors for type validity violations, printing which field in the type the problem occurs at and so on.
However, we don't see these errors when using e.g. `mem::zeroed` as that uses `assert_zero_valid` to bail out before Miri can detect the UB.
Similar to what we did with `@saethlin's` UB checks, I think we should disable such language UB checks in Miri so that we can get better error messages. If we go for this we should probably say this in the intrinsic docs as well so that people don't think they can rely on these intrinsics catching anything.
Furthermore, I slightly changed `MaybeUninit::assume_init` so that the `.value` field does not show up in error messages any more.
`@rust-lang/miri` what do you think?
Remove some unsized tuple impls now that we don't support unsizing tuples anymore
Since https://github.com/rust-lang/rust/pull/137728 there is no sound way to create unsized tuples anymore. While we can't remove them from the language (tried here: https://github.com/rust-lang/rust/pull/138093) due to people using `PhantomData<(T, U)>` where `U: ?Sized` (they'd have to use `(PhantomData<T>, PhantomData<U>)` now), we can remove the impls from libcore I believe.
r? libs I guess?
Derive `Copy` and `Hash` for `IntErrorKind`
This PR derives `Copy` and `Hash` for `IntErrorKind` to make it easier to work with. (see #131826)
I think an argument could be made to also derive `PartialOrd` + `Ord` as well given that other error kinds in the std like [`io::ErrorKind`](https://doc.rust-lang.org/src/std/io/error.rs.html#212-428) do this. Granted these seem much less useful for errors.
Fixes https://github.com/rust-lang/rust/issues/131826
Implement `Random` for tuple
Implement `Random` for tuples of arity 12 or less. Each element is expected to implement `Random`.
I think it's OK to implement this trait for the following types:
- Primitive integer types and `bool`
- Arrays and tuples of the above values
- ~~`NonZero<T>`~~, `Saturating<T>` and `Wrapping<T>`
The necessity of this trait is debated (<https://github.com/rust-lang/rust/issues/130703#issuecomment-2508889577>), but if we decide to keep it in the future when the `random` module is stabilized, I think it would be useful to have this trait implemented for tuples.
Tracking issue: #130703
r? `@joboet`
Implementation of https://github.com/rust-lang/libs-team/issues/367.
This mainly adds `BorrowedCursor::with_unfilled_buf`, with enables using
the unfilled part of a cursor as a `BorrowedBuf`.
Note that unlike the ACP, `BorrowedCursor::unfilled_buf` was moved to a
`From` conversion. This is more consistent with other ways of creating a
`BorrowedBuf` and hides a bit this conversion that requires unsafe code
to be used correctly.
