| Age | Commit message (Collapse) | Author | Lines |
|---|
|
- Lint non-`impl` functions as well.
- Lint function calls in addition to method calls (such as
`Option::unwrap(…)`).
- Put the lint on the `unwrap` and `expect` node instead of the function
signature. This lets the user `#[allow]` specific `unwrap()` or
`expect()` calls.
- Do not lint inside closures, `const` and `static`.
- Do not mix warnings about `Option` and `Result`.
|
|
changelog: none
|
|
Port `#[crate_name]` to the new attribute parsing infrastructure
r? `@fmease`
Closes rust-lang/rust#137687
|
|
(#15343)
changelog: [`unnested_or_patterns`]: FP on structs with only shorthand
field patterns
fixes rust-lang/rust-clippy#15219
|
|
|
|
|
|
|
|
|
|
fix: Fix opaque generics
|
|
use `Mutability::ptr_str`
replace `matches!` with an equality check
avoid always allocating a `String`
s/cast_expr/cast_from_expr -- for more consistency with the naming in `mod.rs`
|
|
this allows reusing `cast_from` and `cast_to`
one possible problem is that the `if` has an additional
`is_hir_ty_cfg_dependant` check which the let-chain of the original
`check` didn't have.. but maybe this is actually more correct
|
|
|
|
|
|
The parent generics were incorrectly not considered for TAIT.
I'm not convinced we should follow rustc here, also there are items (opaques) with more than 1 parent (opaque -> fn/type alias -> impl/trait) and I'm not sure we properly account for that in all places, but for now I left it as-is.
Also fix a bug where lifetimes' indices were incorrect when there is a self param (they started from 0 instead of 1).
|
|
|
|
Pull recent changes from https://github.com/rust-lang/rust via Josh.
Upstream ref: f6d23413c399fb530be362ebcf25a4e788e16137
Filtered ref: fc132ae45e682a2556f99caed7bca9b8a2e909c8
This merge was created using https://github.com/rust-lang/josh-sync.
|
|
This updates the rust-version file to f6d23413c399fb530be362ebcf25a4e788e16137.
|
|
All function pointers are currently treated as unaligned anyway;
any change implementing function pointer alignment during consteval should add
tests that it works properly on arm::t32 functions.
|
|
Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#144531 (Add lint against integer to pointer transmutes)
- rust-lang/rust#145307 (Fix `LazyLock` poison panic message)
- rust-lang/rust#145554 (rustc-dev-guide subtree update)
- rust-lang/rust#145798 (Use unnamed lifetime spans as primary spans for `MISMATCHED_LIFETIME_SYNTAXES`)
- rust-lang/rust#145799 (std/src/lib.rs: mention "search button" instead of "search bar")
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Use unnamed lifetime spans as primary spans for `MISMATCHED_LIFETIME_SYNTAXES`
Fixes https://github.com/rust-lang/rust/issues/145772
This PR changes the primary span(s) of the `MISMATCHED_LIFETIME_SYNTAXES` to point to the *unnamed* lifetime spans in both the inputs and *outputs* of the function signature. As reported in rust-lang/rust#145772, this should make it so that IDEs highlight the spans of the actionable part of this lint, rather than just the (possibly named) input spans like they do today.
This could be tweaked further perhaps, for example for `fn foo(_: T<'_>) -> T`, we don't need to highlight the elided lifetime if the actionable part is to change only the return type to `T<'_>`, but I think it's improvement on what's here today, so I think that should be follow-up since I think the logic might get a bit hairy.
cc ```@shepmaster```
|
|
std/src/lib.rs: mention "search button" instead of "search bar"
r? ```@GuillaumeGomez```
|
|
Use unnamed lifetime spans as primary spans for `MISMATCHED_LIFETIME_SYNTAXES`
Fixes https://github.com/rust-lang/rust/issues/145772
This PR changes the primary span(s) of the `MISMATCHED_LIFETIME_SYNTAXES` to point to the *unnamed* lifetime spans in both the inputs and *outputs* of the function signature. As reported in rust-lang/rust#145772, this should make it so that IDEs highlight the spans of the actionable part of this lint, rather than just the (possibly named) input spans like they do today.
This could be tweaked further perhaps, for example for `fn foo(_: T<'_>) -> T`, we don't need to highlight the elided lifetime if the actionable part is to change only the return type to `T<'_>`, but I think it's improvement on what's here today, so I think that should be follow-up since I think the logic might get a bit hairy.
cc ```@shepmaster```
|
|
rustc-dev-guide subtree update
Subtree update of `rustc-dev-guide` to https://github.com/rust-lang/rustc-dev-guide/commit/c22150808bc96df8c8666d2f4b89cbab10e1ce0d.
Created using https://github.com/rust-lang/josh-sync.
r? ```@ghost```
|
|
Add lint against integer to pointer transmutes
# `integer_to_ptr_transmutes`
*warn-by-default*
The `integer_to_ptr_transmutes` lint detects integer to pointer transmutes where the resulting pointers are undefined behavior to dereference.
### Example
```rust
fn foo(a: usize) -> *const u8 {
unsafe {
std::mem::transmute::<usize, *const u8>(a)
}
}
```
```
warning: transmuting an integer to a pointer creates a pointer without provenance
--> a.rs:1:9
|
158 | std::mem::transmute::<usize, *const u8>(a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is dangerous because dereferencing the resulting pointer is undefined behavior
= note: exposed provenance semantics can be used to create a pointer based on some previously exposed provenance
= help: if you truly mean to create a pointer without provenance, use `std::ptr::without_provenance_mut`
= help: for more information about transmute, see <https://doc.rust-lang.org/std/mem/fn.transmute.html#transmutation-between-pointers-and-integers>
= help: for more information about exposed provenance, see <https://doc.rust-lang.org/std/ptr/index.html#exposed-provenance>
= note: `#[warn(integer_to_ptr_transmutes)]` on by default
help: use `std::ptr::with_exposed_provenance` instead to use a previously exposed provenance
|
158 - std::mem::transmute::<usize, *const u8>(a)
158 + std::ptr::with_exposed_provenance::<u8>(a)
|
```
### Explanation
Any attempt to use the resulting pointers are undefined behavior as the resulting pointers won't have any provenance.
Alternatively, `std::ptr::with_exposed_provenance` should be used, as they do not carry the provenance requirement or if the wanting to create pointers without provenance `std::ptr::without_provenance_mut` should be used.
See [std::mem::transmute] in the reference for more details.
[std::mem::transmute]: https://doc.rust-lang.org/std/mem/fn.transmute.html
--------
People are getting tripped up on this, see https://github.com/rust-lang/rust/issues/128409 and https://github.com/rust-lang/rust/issues/141220. There are >90 cases like these on [GitHub search](https://github.com/search?q=lang%3Arust+%2Ftransmute%3A%3A%3Cu%5B0-9%5D*.*%2C+%5C*const%2F&type=code).
Fixes https://github.com/rust-lang/rust-clippy/issues/13140
Fixes https://github.com/rust-lang/rust/issues/141220
Fixes https://github.com/rust-lang/rust/issues/145523
`@rustbot` labels +I-lang-nominated +T-lang
cc `@traviscross`
r? compiler
|
|
Fix `LazyLock` poison panic message
Fixes the issue raised in https://github.com/rust-lang/rust/pull/144872#issuecomment-3151100248
r? ```@Amanieu```
|
|
Add lint against integer to pointer transmutes
# `integer_to_ptr_transmutes`
*warn-by-default*
The `integer_to_ptr_transmutes` lint detects integer to pointer transmutes where the resulting pointers are undefined behavior to dereference.
### Example
```rust
fn foo(a: usize) -> *const u8 {
unsafe {
std::mem::transmute::<usize, *const u8>(a)
}
}
```
```
warning: transmuting an integer to a pointer creates a pointer without provenance
--> a.rs:1:9
|
158 | std::mem::transmute::<usize, *const u8>(a)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: this is dangerous because dereferencing the resulting pointer is undefined behavior
= note: exposed provenance semantics can be used to create a pointer based on some previously exposed provenance
= help: if you truly mean to create a pointer without provenance, use `std::ptr::without_provenance_mut`
= help: for more information about transmute, see <https://doc.rust-lang.org/std/mem/fn.transmute.html#transmutation-between-pointers-and-integers>
= help: for more information about exposed provenance, see <https://doc.rust-lang.org/std/ptr/index.html#exposed-provenance>
= note: `#[warn(integer_to_ptr_transmutes)]` on by default
help: use `std::ptr::with_exposed_provenance` instead to use a previously exposed provenance
|
158 - std::mem::transmute::<usize, *const u8>(a)
158 + std::ptr::with_exposed_provenance::<u8>(a)
|
```
### Explanation
Any attempt to use the resulting pointers are undefined behavior as the resulting pointers won't have any provenance.
Alternatively, `std::ptr::with_exposed_provenance` should be used, as they do not carry the provenance requirement or if the wanting to create pointers without provenance `std::ptr::without_provenance_mut` should be used.
See [std::mem::transmute] in the reference for more details.
[std::mem::transmute]: https://doc.rust-lang.org/std/mem/fn.transmute.html
--------
People are getting tripped up on this, see https://github.com/rust-lang/rust/issues/128409 and https://github.com/rust-lang/rust/issues/141220. There are >90 cases like these on [GitHub search](https://github.com/search?q=lang%3Arust+%2Ftransmute%3A%3A%3Cu%5B0-9%5D*.*%2C+%5C*const%2F&type=code).
Fixes https://github.com/rust-lang/rust-clippy/issues/13140
Fixes https://github.com/rust-lang/rust/issues/141220
Fixes https://github.com/rust-lang/rust/issues/145523
`@rustbot` labels +I-lang-nominated +T-lang
cc `@traviscross`
r? compiler
|
|
|
|
Add ReturnExpr completion suggest
|
|
|
|
replace_arith_op not applicable on selected
|
|
|
|
Rollup of 14 pull requests
Successful merges:
- rust-lang/rust#143898 (opt-dist: rebuild rustc when doing static LLVM builds)
- rust-lang/rust#144452 (std/sys/fd: Relax `READ_LIMIT` on Darwin)
- rust-lang/rust#145234 (match exhaustiveness diagnostics: show a trailing comma on singleton tuple consructors in witness patterns (and clean up a little))
- rust-lang/rust#145515 (Optimize `char::encode_utf8`)
- rust-lang/rust#145540 (interpret/allocation: get_range on ProvenanceMap)
- rust-lang/rust#145670 (port `sanitize` attribute to the new parsing infrastructure)
- rust-lang/rust#145713 (next-solver: fix `feature(const_trait_impl)` bootstrap)
- rust-lang/rust#145729 (Remove two duplicated crates)
- rust-lang/rust#145744 (miri: also detect aliasing of in-place argument and return place)
- rust-lang/rust#145774 (Remove default opts from config)
- rust-lang/rust#145781 (Remove profile section from Clippy)
- rust-lang/rust#145782 (rustdoc: make attributes render consistently)
- rust-lang/rust#145787 (citool: cleanup `mismatched_lifetime_syntaxes` warnings)
- rust-lang/rust#145791 (Fix ICE when validating transmuting ZST to inhabited enum)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Reborrows are consecutive deref then ref. Make it the default because reborrows are mostly useless to the programmer.
Also rename `rust-analyzer.inlayHints.expressionAdjustmentHints.enable: "reborrow"` to `rust-analyzer.inlayHints.expressionAdjustmentHints.enable: "borrows"`, as it's not about reborrows but about any ref/deref and it's confusing with the new setting.
|
|
continuation of https://github.com/rust-lang/rust-clippy/pull/15519, see
there for the commit structure
AFAICT this finally resolves
https://github.com/rust-lang/rust-clippy/issues/7784
changelog: none
|
|
(#15437)
Fixes: rust-lang/rust-clippy#15127
changelog: [`cast_slice_from_raw_parts`]: check for implicit cast to raw
slice pointer
changelog: [`cast_slice_from_raw_parts`]: properly select `std/core`
<!-- TRIAGEBOT_START -->
<!-- TRIAGEBOT_SUMMARY_START -->
### Summary Notes
-
[Feature-freeze](https://github.com/rust-lang/rust-clippy/pull/15437#pullrequestreview-3148101874)
by [samueltardieu](https://github.com/samueltardieu)
*Managed by `@rustbot`—see
[help](https://forge.rust-lang.org/triagebot/note.html) for details*
<!-- TRIAGEBOT_SUMMARY_END -->
<!-- TRIAGEBOT_END -->
|
|
Signed-off-by: Zihan <zihanli0822@gmail.com>
|
|
changelog: [`cast_slice_from_raw_parts`]: check for implicit cast to raw slice pointer
Signed-off-by: Zihan <zihanli0822@gmail.com>
|
|
Currently there's an "implicit" invariant in this lint's code, which has
been bugging me for a while (but especially so because I recently wanted
to extend this lint): when we see a `vec![]` expression that we can't
suggest changing to an array because of surrounding expressions (e.g.
it's passed to a function that requires a `Vec`), we *must* insert that
into this `self.span_to_lint_map` map with `None`.
See FP issue #11861 for the motivating example of why this lint is doing
that (and the doc comment in the code I added).
This invariant is really easy to miss and error prone: in the old code,
every other `} else {` branch needed a `self.span_to_lint_map.insert(..,
None)` call.
This PR moves out the logic that checks if an expression *needs* to be a
vec based on its surrounding environment. This way we can cover all
cases with one `else` at its callsite and only need to insert `None` in
one isolated place.
I was also working on extending this lint with another pattern, where
refactoring the "does this expression need to be a vec or does a slice
work too" into its own function would be very convenient.
(Tbh, I don't think this invariant/FP actually matters much in practice,
because it's a bit of an edge case IMO. I don't think it's really worth
all the complexity (even though I was the one to suggest how we could
fix this in the linked issue). This is also already an issue with every
other lint that can change an expression's type. I also don't know if
this is compatible with "incremental lints", which IIUC work per-module
(I know that MSRV handling recently had to change due to that). In any
case, I just decided to keep it for now so that this is purely an
internal refactor without user facing changes.)
Fixes #14531 (indirectly, added a test for it)
changelog: none
|
|
Add let in let-chain completion support
|
|
|
|
|
|
Fix `else` completion in `let _ = if x {} $0`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
changelog: none
|
|
convert_integer_literal not on selected
|
