Add a tidy check for files with over 3,000 lines
Files with a large number of lines can cause issues in GitHub (e.g. https://github.com/rust-lang/rust/issues/60015) and also tend to be indicative of opportunities to refactor into less monolithic structures.
This adds a new check to tidy to warn against files that have more than 3,000 lines, as suggested in https://github.com/rust-lang/rust/issues/60015#issuecomment-483868594. (This number was chosen fairly arbitrarily as a reasonable indicator of size.) This check can be ignored with `// ignore-tidy-filelength`.
Existing files with greater than 3,000 lines currently ignore the check, but this helps us spot when files are getting too large. (We might try to split up all files larger than this in the future, as in https://github.com/rust-lang/rust/issues/60015).
Add Pin::{into_inner,into_inner_unchecked}
These functions are useful for unsafe code that needs to temporarily pull smart pointers out of the `Pin`, e.g. [the change that inspired them](b4361780fa (diff-1a4e0ba4d1b539412ca576411ec6c7c2R258)) is taking a `Pin<Box<dyn Future>>`, turning it into a `*mut dyn Future` via `Box::into_raw(unsafe { Pin::into_inner_unchecked(pin) })` then later dropping this via `drop(Pin::from(Box::from_raw(ptr)))`. This can be accomplished today via `{ let ptr = unsafe { Pin::get_unchecked_mut(pin.as_mut()) } as *mut dyn Future; mem::forget(pin); ptr }`, but this is far more complicated and loses out on the symmetry of using `Box::into_raw` and `Box::from_raw`.
I'll extend the documentation on what guarantees `into_inner_unchecked` needs to uphold once I get some feedback on whether this API is wanted or not.
r? @withoutboats
Implement saturating_abs() and saturating_neg() functions for signed integer types
Similar to wrapping_abs() / wrapping_neg() functions but saturating at the numeric bounds instead of wrapping around. Complements the existing set of functions with saturation mechanics.
cc #59983
Similar to wrapping_abs() / wrapping_neg() functions but saturating at
the numeric bounds instead of wrapping around. Complements the existing
set of functions with saturation mechanics.
Warn on unused results for operation methods on nums
From a suggestion by @llogiq
Adds a `#[must_use]` attribute to operation methods on integers that take self by value as the first operand and another value as the second. It makes it clear that these methods return the result of the operation instead of mutating `self`, which is the source of a rather embarrassing bug I had in a codebase of mine recently...
As an example:
```rust
struct Int {
value: i64,
}
impl Int {
fn add(&mut self, other: i64) {
self.value.wrapping_add(other);
}
}
```
Will produce a warning like:
```
warning: unused return value of `core::num::<impl i64>::wrapping_add` that must be used
--> src/main.rs:7:7
|
7 | self.value.wrapping_add(other);
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: #[warn(unused_must_use)] on by default
= note: this returns the result of the operation, without modifying the original
```
If this is something we're on board with, we could do something similar for `f32` and `f64` too. There are probably other methods on integers that make sense.
Fixed outdated reference to `waker` argument; now futures are passed a
`Context`, from which one can obtain a `waker`.
Cleaned up explanation of what happens when you call `poll` on a completed
future. It doesn't make sense to say that `poll` implementations can't cause
memory unsafety; no safe function is ever allowed to cause memory unsafety, so
why mention it here? It seems like the intent is to say that the `Future` trait
doesn't say what the consequences of excess polls will be, and they might be
bad; but that the usual constraints that Rust imposes on any non-`unsafe`
function still apply. It's also oddly specific to say 'memory corruption'
instead of just 'undefined behavior'; UB is a bit jargony, so the text should
provide examples.
Fix small errors in docs for `rchunks_exact` and `rchunks_exact_mut`.
The documentation for `rchunks_exact` said it started at the beginning
of the slice, bit it actually starts at the end of the slice.
In addition, there were a couple of "of the slice of the slice"
duplicate phrases going on for `rchunks_exact` and `rchunks_exact_mut`.
This fixes#60068.
implement specialized nth_back() for Bytes, Fuse and Enumerate
Hi,
After my first PR has been successfully merged, here is my second pull request :-)
Also this PR contains some specializations for the problem discussed in #54054.
The documentation for `rchunks_exact` said it started at the beginning
of the slice, bit it actually starts at the end of the slice.
In addition, there were a couple of "of the slice of the slice"
duplicate phrases going on for `rchunks_exact` and `rchunks_exact_mut`.
This fixes#60068.
bump stdsimd; make intra_doc_link_resolution_failure an error again; make lints more consistent
I made `intra_doc_link_resolution_failure` warn so that it would properly respect `deny-warnings = false` in `config.toml`. `#[warn]` still become errors with `-D warnings` so I thought this was fine.
Turns out however that we don't pass `-D warnings` when running rustdoc, so for additional rustdoc-lints we need to set them to `deny`.
Also sue the opportunity to make the lint flags more consistent between libcore, liballoc, libstd.
Cc @gnzlbg for the *big* stdsimd update.
Remove strange formatting in `Ordering` docs.
I can't really fathom what the intent of the brackets is. The [original PR](#12956) doesn't give any hints. I think it seems fine without them.
