| Age | Commit message (Collapse) | Author | Lines |
|
|
|
|
|
Rollup of 16 pull requests
Successful merges:
- #53311 (Window Mutex: Document that we properly initialize the SRWLock)
- #53503 (Discourage overuse of mem::forget)
- #53545 (Fix #50865: ICE on impl-trait returning functions reaching private items)
- #53559 (add macro check for lint)
- #53562 (Lament the invincibility of the Turbofish)
- #53563 (use String::new() instead of String::from(""), "".to_string(), "".to_owned() or "".into())
- #53592 (docs: minor stylistic changes to str/string docs)
- #53594 (Update RELEASES.md to include clippy-preview)
- #53600 (Fix a grammatical mistake in "expected generic arguments" errors)
- #53614 (update nomicon and book)
- #53617 (tidy: Stop requiring a license header)
- #53618 (Add missing fmt examples)
- #53636 (Prefer `.nth(n)` over `.skip(n).next()`.)
- #53644 (Use SmallVec for SmallCStr)
- #53664 (Remove unnecessary closure in rustc_mir/build/mod.rs)
- #53666 (Added rustc_codegen_llvm to compiler documentation.)
|
|
Prefer `.nth(n)` over `.skip(n).next()`.
Found by clippy.
|
|
Add missing fmt examples
r? @QuietMisdreavus
|
|
|
|
|
|
|
|
Found by clippy.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Suggest direct raw-pointer dereference
People often come looking for some kind of `as_ref_unchecked` method on
raw pointers that would give them `&T` and not `Option<&T>` when they
are sure the pointer is not NULL.
There's no such method, but taking a reference of the dereferenced
pointer accomplishes the same thing. Therefore, suggest using that, at
the `as_ref` site ‒ it's a place people are likely going to look into.
|
|
|
|
|
|
People often come looking for some kind of `as_ref_unchecked` method on
raw pointers that would give them `&T` and not `Option<&T>` when they
are sure the pointer is not NULL.
There's no such method, but taking a reference of the dereferenced
pointer accomplishes the same thing. Therefore, suggest using that, at
the `as_ref` site ‒ it's a place people are likely going to look into.
|
|
Replace usages of ptr::offset with ptr::{add,sub}.
Rust provides these helper methods – so let's use them!
|
|
expand the documentation on the `Unpin` trait
provides an overview of the Pin API which the trait is for,
and show how it can be used in making self referencial structs
part of #49150
|
|
add individual docs to `core::num::NonZero*`
|
|
Fix typos found by codespell.
|
|
When closure with no arguments was expected, suggest wrapping
Fix #49694.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
debug_assert to ensure that from_raw_parts is only used properly aligned
This does not help nearly as much as I would hope because everybody uses the distributed libstd which is compiled without debug assertions. For this reason, I am not sure if this is even worth it. OTOH, this would have caught the misalignment fixed by https://github.com/rust-lang/rust/issues/42789 *if* there had been any tests actually using ZSTs with alignment >1 (we have a CI runner which has debug assertions in libstd enabled), and it seems to currently [fail in the rg testsuite](https://ci.appveyor.com/project/rust-lang/rust/build/1.0.8403/job/v7dfdcgn8ay5j6sb). So maybe it is worth it, after all.
I have seen the attribute `#[rustc_inherit_overflow_checks]` in some places, does that make it so that the *caller's* debug status is relevant? Is there a similar attribute for `debug_assert!`? That could even subsume `rustc_inherit_overflow_checks`: Something like `rustc_inherit_debug_flag` could affect *all* places that change the generated code depending on whether we are in debug or release mode. In fact, given that we have to keep around the MIR for generic functions anyway, is there ever a reason *not* to handle the debug flag that way? I guess currently we apply debug flags like `cfg` so this is dropped early during the MIR pipeline?
EDIT: I learned from @eddyb that because of how `debug_assert!` works, this is not realistic. Well, we could still have it for the rustc CI runs and then maybe, eventually, when libstd gets compiled client-side and there is both a debug and a release build... then this will also benefit users.^^
|
|
|
|
`{to,from}_{ne,le,be}_bytes` for unsigned integer types
Same as https://github.com/rust-lang/rust/pull/51919 did for signed integers.
Tracking issue: https://github.com/rust-lang/rust/issues/52963
|
|
|
|
Use #[non_exhaustive] on internal enums
This replaces `__Nonexhaustive` variants (and variants thereof) with `#[non_exhaustive]`. These were mostly unstable previously, with the exception of the `cloudabi` enums and `Level` in proc_macro: these were `#[doc(hidden)]`, so clearly intended not to be used directly. It should be safe to replace all of these.
|
|
Don't accept non-string literals for the format string in writeln
This is to improve diagnostics.
`println` and `eprintln` were already fixed by #52394.
Fixes #30143
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Same as https://github.com/rust-lang/rust/pull/51919 did for signed integers.
Tracking issue: https://github.com/rust-lang/rust/issues/52963
|
|
unsized ManuallyDrop
I think this matches what @eddyb had in https://github.com/rust-lang/rust/pull/52711 originally.
~~However, I have never added a `CoerceUnsized` before so I am not sure if I did this right. I copied the `unstable` attribute on the `impl` from elsewhere, but AFAIK it is useless because `impl`'s are insta-stable... so shouldn't this rather say "stable since 1.30"?~~
This is insta-stable and hence requires FCP, at least.
Fixes https://github.com/rust-lang/rust/issues/47034
|