| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Add enum_intrinsics_non_enums lint
There is a clippy lint to prevent calling [`mem::discriminant`](https://doc.rust-lang.org/std/mem/fn.discriminant.html) with a non-enum type. I think the lint is worthy of being included in rustc, given that `discriminant::<T>()` where `T` is a non-enum has an unspecified return value, and there are no valid use cases where you'd actually want this.
I've also made the lint check [variant_count](https://doc.rust-lang.org/core/mem/fn.variant_count.html) (#73662).
closes #83899
|
|
Rollup of 7 pull requests
Successful merges:
- #89655 (bootstrap: don't use `--merges` to look for commit hashes for downloading artifacts)
- #89726 (Add #[must_use] to alloc constructors)
- #89729 (Add #[must_use] to core and std constructors)
- #89743 (Fix RUSTC_LOG handling)
- #89753 (Add #[must_use] to from_value conversions)
- #89754 (Cleanup .item-table CSS)
- #89761 (:arrow_up: rust-analyzer)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
r=joshtriplett
Add #[must_use] to from_value conversions
I added two methods to the list myself. Clippy did not flag them because they take `mut` args, but neither modifies their argument.
```rust
core::str const unsafe fn from_utf8_unchecked_mut(v: &mut [u8]) -> &mut str;
std::ffi::CString unsafe fn from_raw(ptr: *mut c_char) -> CString;
```
I put a custom note on `from_raw`:
```rust
#[must_use = "call `drop(from_raw(ptr))` if you intend to drop the `CString`"]
pub unsafe fn from_raw(ptr: *mut c_char) -> CString {
```
Parent issue: #89692
r? ``@joshtriplett``
|
|
r=joshtriplett
Add #[must_use] to core and std constructors
Parent issue: #89692
r? ``@joshtriplett``
|
|
Add #[must_use] to alloc constructors
Added `#[must_use]`. to the various forms of `new`, `pin`, and `with_capacity` in the `alloc` crate. No extra explanations given as I couldn't think of anything useful to add.
I figure this deserves extra scrutiny compared to the other PRs I've done so far. In particular:
* The 4 `pin`/`pin_in` methods I touched. Are there legitimate use cases for pinning and not using the result? Pinning's a difficult concept I'm not very comfortable with.
* `Box`'s constructors. Do people ever create boxes just for the side effects... allocating or zeroing out memory?
Parent issue: #89692
r? ``@joshtriplett``
|
|
Apply clippy suggestions for rustc and core
|
|
|
|
r=joshtriplett
Add #[must_use] to conversions that move self
Everything here got the same message. Is the wording okay?
```rust
#[must_use = "`self` will be dropped if the result is not used"]
```
I want to draw attention to these methods in particular:
```rust
alloc::sync::Arc<MaybeUninit<T>> unsafe fn assume_init(self) -> Arc<T>;
alloc::sync::Arc<[MaybeUninit<T>]> unsafe fn assume_init(self) -> Arc<[T]>;
core::pin::Pin<&'a mut T> const fn into_ref(self) -> Pin<&'a T>;
core::pin::Pin<&'a mut T> const fn get_mut(self) -> &'a mut T;
core::pin::Pin<&'a mut T> const unsafe fn get_unchecked_mut(self) -> &'a mut T;
core::pin::Pin<&'a mut T> unsafe fn map_unchecked_mut(self, func: F) -> Pin<&'a mut U>;
core::pin::Pin<&'a mut Pin<P>> fn as_deref_mut(self) -> Pin<&'a mut P::Target>;
```
Parent issue: #89692
r? `@joshtriplett`
|
|
|
|
|
|
r=Mark-Simulacrum
Apply clippy suggestions for std
|
|
r=petrochenkov
Stabilize proc_macro::is_available
Tracking issue: https://github.com/rust-lang/rust/issues/71436
The FCP for the stabilization of `proc_macro::is_available` has completed.
|
|
Add #[must_use] to math and bit manipulation methods
Also tidied up a few other nearby `#[must_use]`s.
Parent issue: #89692
|
|
Add #[must_use] to char escape methods
Parent issue: #89692
|
|
Add #[must_use] to is_condition tests
There's nothing insightful to say about these so I didn't write any extra explanations.
Parent issue: #89692
|
|
Cfg hide no_global_oom_handling and no_fp_fmt_parse
These are unstable sysroot customisation cfg options that only projects building their own sysroot will use (e.g. Rust-for-linux). Most users shouldn't care. `no_global_oom_handling` can be especially annoying since it's applied on many commonly used alloc crate methods (e.g. `Box::new`, `Vec::push`).
r? ```@GuillaumeGomez```
|
|
docs: `std::hash::Hash` should ensure prefix-free data
Attempt to synthesize the discussion in #89429 into a suggestion regarding `Hash` implementations (not a hard requirement).
Closes #89429.
|
|
Improve docs for int_log
* Clarify rounding.
* Avoid "wrapping" wording.
* Omit wrong claim on 0 only being returned in error cases.
* Typo fix for one_less_than_next_power_of_two.
|
|
Fix documentation in Cell
|
|
|
|
|
|
Use get_unchecked in str::[r]split_once
This PR removes indices checking in `str::split_once` and `str::rsplit_once` methods.
|
|
|
|
Add new tier-3 target: armv7-unknown-linux-uclibceabihf
This change adds a new tier-3 target: armv7-unknown-linux-uclibceabihf
This target is primarily used in embedded linux devices where system resources are slim and glibc is deemed too heavyweight. Cross compilation C toolchains are available [here](https://toolchains.bootlin.com/) or via [buildroot](https://buildroot.org).
The change is based largely on a previous PR #79380 with a few minor modifications. The author of that PR was unable to push the PR forward, and graciously allowed me to take it over.
Per the [target tier 3 policy](https://github.com/rust-lang/rfcs/blob/master/text/2803-target-tier-policy.md), I volunteer to be the "target maintainer".
This is my first PR to Rust itself, so I apologize if I've missed things!
|
|
|
|
|
|
Also tidied up a few other nearby `#[must_use]`s.
|
|
|
|
There's nothing insightful to say about these so I didn't write any
extra explanations.
|
|
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
|
|
|
|
|
|
Add documentation to boxed conversions
Among other changes, documents whether allocations are necessary
to complete the type conversion.
Part of #51430, supersedes #89199
|
|
Update to Unicode 14.0
The Unicode Standard [announced Version 14.0](https://home.unicode.org/announcing-the-unicode-standard-version-14-0/) on September 14, 2021, and this pull request updates the generated tables in `core` accordingly.
This did require a little prep-work in `unicode-table-generator`. First, #81358 had modified the generated file instead of the tool, so that change is now reflected in the tool as well. Next, I found that the "Alphabetic" property in version 14 was panicking when generating a bitset, "cannot pack 264 into 8 bits". We've been using the skiplist for that anyway, so I changed this to fail gracefully. Finally, I confirmed that the tool still created the exact same tables for 13 before moving to 14.
|
|
std: Stabilize command_access
Tracking issue: #44434 (not yet closed but the FCP is done so that should be soon).
|
|
stack overflow handler specific openbsd change.
|
|
Add 'core::array::from_fn' and 'core::array::try_from_fn'
These auxiliary methods fill uninitialized arrays in a safe way and are particularly useful for elements that don't implement `Default`.
```rust
// Foo doesn't implement Default
struct Foo(usize);
let _array = core::array::from_fn::<_, _, 2>(|idx| Foo(idx));
```
Different from `FromIterator`, it is guaranteed that the array will be fully filled and no error regarding uninitialized state will be throw. In certain scenarios, however, the creation of an **element** can fail and that is why the `try_from_fn` function is also provided.
```rust
#[derive(Debug, PartialEq)]
enum SomeError {
Foo,
}
let array = core::array::try_from_fn(|i| Ok::<_, SomeError>(i));
assert_eq!(array, Ok([0, 1, 2, 3, 4]));
let another_array = core::array::try_from_fn(|_| Err(SomeError::Foo));
assert_eq!(another_array, Err(SomeError::Foo));
```
|
|
Add #[must_use] to string/char transformation methods
These methods could be misconstrued as modifying their arguments instead of returning new values.
Where possible I made the note recommend a method that does mutate in place.
Parent issue: #89692
|
|
r=joshtriplett
Add #[must_use] to stdin/stdout/stderr locks
Affected methods:
```rust
std::io fn stdin_locked() -> StdinLock<'static>;
std::io::Stdin fn lock(&self) -> StdinLock<'_>;
std::io fn stdout_locked() -> StdoutLock<'static>;
std::io::Stdout fn lock(&self) -> StdoutLock<'_>;
std::io fn stderr_locked() -> StderrLock<'static>;
std::io::Stderr fn lock(&self) -> StderrLock<'_>;
```
Parent issue: https://github.com/rust-lang/rust/issues/89692
|
|
Fix minor std::thread documentation typo
callers of spawn_unchecked() need to make sure that the thread
not outlive references in the passed closure, not the other way around.
|
|
String.split_terminator: Add an example when using a slice of chars
|
|
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
|
|
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
Co-authored-by: Laurențiu Nicola <lnicola@users.noreply.github.com>
|
|
Co-authored-by: Josh Triplett <josh@joshtriplett.org>
|
|
Optimize File::read_to_end and read_to_string
Reading a file into an empty vector or string buffer can incur unnecessary `read` syscalls and memory re-allocations as the buffer "warms up" and grows to its final size. This is perhaps a necessary evil with generic readers, but files can be read in smarter by checking the file size and reserving that much capacity.
`std::fs::read` and `std::fs::read_to_string` already perform this optimization: they open the file, reads its metadata, and call `with_capacity` with the file size. This ensures that the buffer does not need to be resized and an initial string of small `read` syscalls.
However, if a user opens the `File` themselves and calls `file.read_to_end` or `file.read_to_string` they do not get this optimization.
```rust
let mut buf = Vec::new();
file.read_to_end(&mut buf)?;
```
I searched through this project's codebase and even here are a *lot* of examples of this. They're found all over in unit tests, which isn't a big deal, but there are also several real instances in the compiler and in Cargo. I've documented the ones I found in a comment here:
https://github.com/rust-lang/rust/issues/89516#issuecomment-934423999
Most telling, the documentation for both the `Read` trait and the `Read::read_to_end` method both show this exact pattern as examples of how to use readers. What this says to me is that this shouldn't be solved by simply fixing the instances of it in this codebase. If it's here it's certain to be prevalent in the wider Rust ecosystem.
To that end, this commit adds specializations of `read_to_end` and `read_to_string` directly on `File`. This way it's no longer a minor footgun to start with an empty buffer when reading a file in.
A nice side effect of this change is that code that accesses a `File` as `impl Read` or `dyn Read` will benefit. For example, this code from `compiler/rustc_serialize/src/json.rs`:
```rust
pub fn from_reader(rdr: &mut dyn Read) -> Result<Json, BuilderError> {
let mut contents = Vec::new();
match rdr.read_to_end(&mut contents) {
```
Related changes:
- I also added specializations to `BufReader` to delegate to `self.inner`'s methods. That way it can call `File`'s optimized implementations if the inner reader is a file.
- The private `std::io::append_to_string` function is now marked `unsafe`.
- `File::read_to_string` being more efficient means that the performance note for `io::read_to_string` can be softened. I've added `@camelid's` suggested wording from https://github.com/rust-lang/rust/issues/80218#issuecomment-936806502.
r? `@joshtriplett`
|
|
These methods could be misconstrued as modifying their arguments instead
of returning new values.
Where possible I made the note recommend a method that does mutate in
place.
|
|
|
|
callers of spawn_unchecked() need to make sure that the thread
not outlive references in the passed closure, not the other way around.
|
|
|
|
|
