| Age | Commit message (Collapse) | Author | Lines |
|
(clippy::write_with_newline)
|
|
fix various typos
|
|
Don't redundantly repeat field names (clippy::redundant_field_names)
|
|
|
|
|
|
|
|
|
|
Error::description is deprecated as of version 1.42, as the commit was
not in the release for 1.41.
|
|
even more clippy cleanups
* Don't pass &mut where immutable reference (&) is sufficient (clippy::unnecessary_mut_passed)
* Use more efficient &&str to String conversion (clippy::inefficient_to_string)
* Don't always eval arguments inside .expect(), use unwrap_or_else and closure. (clippy::expect_fun_call)
* Use righthand '&' instead of lefthand "ref". (clippy::toplevel_ref_arg)
* Use simple 'for i in x' loops instead of 'while let Some(i) = x.next()' loops on iterators. (clippy::while_let_on_iterator)
* Const items have by default a static lifetime, there's no need to annotate it. (clippy::redundant_static_lifetimes)
* Remove redundant patterns when matching ( x @ _ to x) (clippy::redundant_pattern)
|
|
|
|
it. (clippy::redundant_static_lifetimes)
|
|
|
|
Stabilize assoc_int_consts associated int/float constants
The next step in RFC https://github.com/rust-lang/rfcs/pull/2700 (tracking issue #68490). Stabilizing the associated constants that were added in #68325.
* Stabilize all constants under the `assoc_int_consts` feature flag.
* Update documentation on old constants to say they are soft-deprecated and the new ones should be preferred.
* Update documentation examples to use new constants.
* Remove `uint_macro` and use `int_macro` for all integer types since the macros were identical anyway.
r? @LukasKalbertodt
|
|
Don't convert Results to Options just for matching.
|
|
more cleanups
* use starts_with() instead of chars().next() == Some(x)
* use subsec_micros() instead of subsec_nanos() / 1000
* use for (idx, item) in iter.enumerate() instead of manually counting loop iterations with variables
* use values() or keys() respectively when iterating only over keys or values of maps.
|
|
Remove `usable_size` APIs
This removes the usable size APIs:
- remove `usable_size` (obv)
- change return type of allocating methods to include the allocated size
- remove `_excess` API
r? @Amanieu
closes rust-lang/wg-allocators#17
|
|
|
|
|
|
|
|
|
|
|
|
This allows LLVM to inline the happy path, such that catching unwinding is
zero-cost when no panic occurs. This also allows us to match the code generated
by C++ try/catch.
|
|
|
|
simplify boolean expressions
|
|
r=varkor
Correct comment to match behavior
Corrects the header comment on `saturating_duration_since` to match the behavior of returning 0 if the other timestamp is _later_ than the invocant, not earlier,
This is purely a documentation change, so hopefully it doesn't require an issue; if it does, I'll open one and resubmit.
|
|
remove unneeded .as_ref() calls.
|
|
|
|
|
|
use is_empty() instead of len() == x to determine if structs are empty.
|
|
docs: add mention of async blocks in move keyword docs
Fixes #69298
|
|
|
|
use char instead of &str for single char patterns
|
|
|
|
Fixes #69298
|
|
example:
let s: String = format!("hello").into();
|
|
|
|
|
|
Add primitive module to libcore
This re-exports the primitive types from libcore at `core::primitive` to allow
macro authors to have a reliable location to use them from.
Fixes #44865
|
|
|
|
|
|
|
|
Split non macro portion of unused_doc_comment from macro part into two passes/lints
## Motivation
This change is motivated by the needs of the [spandoc library](https://github.com/yaahc/spandoc). The specific use case is that my macro is removing doc comments when an attribute is applied to a fn with doc comments, but I would like the lint to still appear when I forget to add the `#[spandoc]` attribute to a fn, so I don't want to have to silence the lint globally.
## Approach
This change splits the `unused _doc_comment` lint into two lints, `unused_macro_doc_comment` and `unused_doc_comment`. The non macro portion is moved into an `early_lint_pass` rather than a pre_expansion_pass. This allows proc macros to silence `unused_doc_comment` warnings by either adding an attribute to silence it or by removing the doc comment before the early_pass runs.
The `unused_macro_doc_comment` lint however will still be impossible for proc-macros to silence, but the only alternative that I can see is to remove this lint entirely, which I don't think is acceptable / is a decision I'm not comfortable making personally, so instead I opted to split the macro portion of the check into a separate lint so that it can be silenced globally with an attribute if necessary without needing to globally silence the `unused_doc_comment` lint as well, which is still desireable.
fixes https://github.com/rust-lang/rust/issues/67838
|
|
|
|
|
|
Stabilize Once::is_completed
Closes #54890
This function has been around for some time. I haven't seen anyone raise any objections to it. I've personally found it useful myself. It would be nice to finally stabilize it and
|
|
|
|
macOS: avoid calling pthread_self() twice
|
|
|
|
Fix std::fs::copy on WASI target
Previously `std::fs::copy` on wasm32-wasi would reuse code from the `sys_common` module and would successfully copy contents of the file just to fail right before closing it.
This was happening because `sys_common::copy` tries to copy permissions of the file, but permissions are not a thing in WASI (at least yet) and `set_permissions` is implemented as an unconditional runtime error.
This change instead adds a custom working implementation of `std::fs::copy` (like Rust already has on some other targets) that doesn't try to call `set_permissions` and is essentially a thin wrapper around `std::io::copy`.
Fixes #68560.
|
|
danielhenrymantilla:feature/cstring_from_vec_of_nonzerou8, r=KodrAus
Added From<Vec<NonZeroU8>> for CString
Added a `From<Vec<NonZeroU8>>` `impl` for `CString`
# Rationale
- `CString::from_vec_unchecked` is a subtle function, that makes `unsafe` code harder to audit when the generated `Vec`'s creation is non-trivial. This `impl` allows to write safer `unsafe` code thanks to the very explicit semantics of the `Vec<NonZeroU8>` type.
- One such situation is when trying to `.read()` a `CString`, see issue #59229.
- this lead to a PR: #59314, that was closed for being too specific / narrow (it only targetted being able to `.read()` a `CString`, when this pattern could have been generalized).
- the issue suggested another route, based on `From<Vec<NonZeroU8>>`, which is indeed a less general and more concise code pattern.
- quoting @shnatsel:
- > For me the main thing about making this safe is simplifying auditing - people have spent like an hour looking at just this one unsafe block in libflate because it's not clear what exactly is unchecked, so you have to look it up when auditing anyway. This has distracted us from much more serious memory safety issues the library had.
Having this trivial impl in stdlib would turn this into safe code with compiler more or less guaranteeing that it's fine, and save anyone auditing the code a whole lot of time.
|