This adds a hint on `mem::replace`, "if you don't need the old value,
you can just assign the new value directly". This is in similar spirit
to the `must_use` on `ManuallyDrop::take`.
Minor fix and addition to doc comments
1. Fixed doc comment of struct 'rustc_middle::mir::Location'
Currently, the general explanation of the struct appears at the field
explanation section. I moved and changed the doc comments slightly, so
that the general explanation would appear in the proper location in
docs.
2. Added doc comment explaining 'rustc_mir::util::pretty::write_mir_fn'
Unlike other counterparts, brief explanation for this function was missing,
so I added one.
Thank you for reviewing this PR :)
Implement `Clone` for `liballoc::collections::linked_list::Cursor`.
This implements `Clone` for linked list `Cursor`. Implementing `Copy` is also possible here, but i'm not sure whether i should also do it.
r? @Amanieu
Use query to determine whether function needs const checking
Resolves#69615.
The HIR const-checker was checking the `constness` of a function's `fn_sig` to determine whether a function needed const-checking. Now that const trait impls are a thing, this is no longer enough. All code should use the `is_const_fn_raw` query instead, which takes the constness of the impl block into account.
r? @oli-obk
1. Fixed doc comment of struct 'rustc_middle::mir::Location'
Currently, the general explanation of the struct appears at the field
explanation section. I moved and changed the doc comments slightly, so
that the general explanation would appear in the proper location in
docs.
2. Added doc comment explaining 'rustc_mir::util::pretty::write_mir_fn'
Unlike other counterparts, brief explanation for this function was missing,
so I added one.
Thank you for reviewing this PR :)
add lint futures_not_send
changelog: add lint futures_not_send
fixes#5379
~Remark: one thing that can (should?) still be improved is to directly include the error message from the `Send` check so that the programmer stays in the flow. Currently, getting the actual error message requires a restructuring of the code to make the `Send` constraint explicit.~
It now shows all unmet constraints for allowing the Future to be Send.
Fixes issue #4892.
First contribution here 😊 ! Do not hesitate to correct me.
This PR is related to issue #4892 .
# Summary
```rust
-literal.method_call(args)
```
The main idea is to not trigger `clippy::precedence` when the method call is an odd function.
# Example
```rust
// should trigger lint
let _ = -1.0_f64.abs() //precedence of method call abs() and neg ('-') is ambiguous
// should not trigger lint
let _ = -1.0_f64.sin() // sin is an odd function => -sin(x) = sin(-x)
```
# Theory
Rust allows following literals:
- char
- string
- integers
- floats
- byte
- bool
Only integers/floats implements the relevant `std::ops::Neg`.
Following odd functions are implemented on i[8-128] and/or f[32-64]:
- `asin`
- `asinh`
- `atan`
- `atanh`
- `cbrt`
- `fract`
- `round`
- `signum`
- `sin`
- `sinh`
- `tan`
- `tanh `
- `to_degrees`
- `to_radians`
# Implementation
As suggested by `flip1995` in [comment](https://github.com/rust-lang/rust-clippy/issues/4892#issuecomment-568249683), this PR add a whitelist of odd functions and compare method call to the the whitelist before triggering lint.
changelog: Don't trigger [`clippy::precedence`] on odd functions.
Add `ConstKind::Error` and convert `ErrorHandled::Reported` to it.
By replicating the `ty::Error` approach to encoding "an error has occurred", all of the mechanisms that skip redundant/downstream errors are engaged and help out (see the reduction in test output).
This PR also adds `ErrorHandled::Linted` for the lint case because using `ErrorHandled::Reported` *without* having emitted an error that is *guaranteed* to stop compilation, is incorrect now.
r? @oli-obk cc @rust-lang/wg-const-eval @varkor @yodaldevoid
question_mark: don't add `as_ref()` for a call expression
If a call returns a `!Copy` value, it does so regardless of whether `as_ref()` is added. For example, `foo.into_option().as_ref()?` can be simplified to `foo.into_option()?`.
---
changelog: Improved `question_mark` lint suggestion so that it doesn't add redundant `as_ref()`
unit_arg suggestion is not really machine-applicable
This lint suggests replacing any code returining `()`-type with `()` literal, which can change the behavior. e.g. `Ok(do_something())` -> `OK(())`.
---
changelog: none
Fix typo in Default trait docs: Provides -> Provide
An earlier commit (99ed06e) accidentally changed this paragraph from the original, imperative `Provide` to the present tense `Provides`. The latter is indeed the standard for Rustdoc comments relating to a function or method, but this snippet is introducing the `Default` trait in general terms and not talking about any particular function. I believe this change was likely made in error and should be reverted.
Dogfood or_patterns in the standard library
We can start using `or_patterns` in the standard library as a step toward stabilization.
cc #54883 @Centril
reword Miri validity errors: undefined -> uninitialized
I don't think we say "undefined value" or anything like that anywhere in the docs or so, but we do use the term "uninitialized memory", so I think we should do the same here.
Longer-term, I think we should also internally rename "undef" to "uninit".
r? @oli-obk
Hides default fns inside Fuse impl to avoid exposing it to any crate
Fixes#70796
@cuviper I've added some default, private traits to do the job for us. If required, I can expose them to a specific visibility if you want to call these functions for #70332
r? @cuviper
Do not reuse post LTO products when exports change
Do not reuse post lto products when exports change
Generalizes code from PR #67020, which handled case when imports change.
Fix#69798
An earlier commit (99ed06e) accidentally changed this paragraph from the
original, imperative "Provide" to the present tense "Provides". The
latter is indeed the standard for Rustdoc comments relating to a
function or method, but this snippet is introducing the Default trait in
general terms and not talking about any particular function. I believe
this change was likely made in error and should be reverted.
Rollup of 5 pull requests
Successful merges:
- #70611 (Add long error explanation for E0708 #61137)
- #71197 (Don't use the HirId to NodeId map in MIR)
- #71211 (Update cargo)
- #71219 (Minor fixes to doc comments of 'VecDeque')
- #71221 (Dogfood or_patterns in rustdoc)
Failed merges:
r? @ghost
