| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Correctly handle async blocks for NEEDLESS_PASS_BY_REF_MUT
Fixes https://github.com/rust-lang/rust-clippy/issues/11299.
The problem was that the `async block`s are popping a closure which we didn't go into, making it miss the mutable access to the variables.
cc `@Centri3`
changelog: none
|
|
[`useless_conversion`]: only lint on paths to fn items and fix FP in macro
Fixes #11065 (which is actually two issues: an ICE and a false positive)
It now makes sure that the function call path points to a function-like item (and not e.g. a `const` like in the linked issue), so that calling `TyCtxt::fn_sig` later in the lint does not ICE (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616836099).
It *also* makes sure that the expression is not part of a macro call (fixes https://github.com/rust-lang/rust-clippy/issues/11065#issuecomment-1616919639). ~~I'm not sure if there's a better way to check this other than to walk the parent expr chain and see if any of them are expansions.~~ (edit: it doesn't do this anymore)
changelog: [`useless_conversion`]: fix ICE when call receiver is a non-fn item
changelog: [`useless_conversion`]: don't lint if argument is a macro argument (fixes a FP)
r? `@llogiq` (reviewed #10814, which introduced these issues)
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #114194 (Inline trivial (noop) flush calls)
- #114257 (Avoid using `ptr::Unique` in `LinkedList` code)
- #114359 ([library/std] Replace condv while loop with `cvar.wait_while`.)
- #114402 (Fix documentation of impl From<Vec<T>> for Rc<[T]>)
- #114715 (Revert clippy lint [`filter_map_bool_then`])
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This reverts commits 978b1daf99d8326718684381704902fdaaf71b18 and 3235d9d612909bc64550eea3a0d387e1187e93dd.
|
|
Removes a piece of mutable state.
Follow up to #114578.
|
|
r=oli-obk
Store the laziness of type aliases in their `DefKind`
Previously, we would treat paths referring to type aliases as *lazy* type aliases if the current crate had lazy type aliases enabled independently of whether the crate which the alias was defined in had the feature enabled or not.
With this PR, the laziness of a type alias depends on the crate it is defined in. This generally makes more sense to me especially if / once lazy type aliases become the default in a new edition and we need to think about *edition interoperability*:
Consider the hypothetical case where the dependency crate has an older edition (and thus eager type aliases), it exports a type alias with bounds & a where-clause (which are void but technically valid), the dependent crate has the latest edition (and thus lazy type aliases) and it uses that type alias. Arguably, the bounds should *not* be checked since at any time, the dependency crate should be allowed to change the bounds at will with a *non*-major version bump & without negatively affecting downstream crates.
As for the reverse case (dependency: lazy type aliases, dependent: eager type aliases), I guess it rules out anything from slight confusion to mild annoyance from upstream crate authors that would be caused by the compiler ignoring the bounds of their type aliases in downstream crates with older editions.
---
This fixes #114468 since before, my assumption that the type alias associated with a given weak projection was lazy (and therefore had its variances computed) did not necessarily hold in cross-crate scenarios (which [I kinda had a hunch about](https://github.com/rust-lang/rust/pull/114253#discussion_r1278608099)) as outlined above. Now it does hold.
`@rustbot` label F-lazy_type_alias
r? `@oli-obk`
|
|
|
|
Add documentation to has_deref
Documentation of `has_deref` needed some polish to be more clear about where it should be used and what's it's purpose.
cc https://github.com/rust-lang/rust/issues/114401
r? `@RalfJung`
|
|
|
|
Rollup of 9 pull requests
Successful merges:
- #113945 (Fix wrong span for trait selection failure error reporting)
- #114351 ([rustc_span][perf] Remove unnecessary string joins and allocs.)
- #114418 (bump parking_lot to 0.12)
- #114434 (Improve spans for indexing expressions)
- #114450 (Fix ICE failed to get layout for ReferencesError)
- #114461 (Fix unwrap on None)
- #114462 (interpret: add mplace_to_ref helper method)
- #114472 (Reword `confusable_idents` lint)
- #114477 (Account for `Rc` and `Arc` when suggesting to clone)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Improve spans for indexing expressions
fixes #114388
Indexing is similar to method calls in having an arbitrary left-hand-side and then something on the right, which is the main part of the expression. Method calls already have a span for that right part, but indexing does not. This means that long method chains that use indexing have really bad spans, especially when the indexing panics and that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an extra span which is then put into the `fn_span` field in THIR.
r? compiler-errors
|
|
Lots of tiny incremental simplifications of `EmitterWriter` internals
ignore the first commit, it's https://github.com/rust-lang/rust/pull/114088 squashed and rebased, but it's needed to use to use `derive_setters`, as they need a newer `syn` version.
Then this PR starts out with removing many arguments that are almost always defaulted to `None` or `false` and replace them with builder methods that can set these fields in the few cases that want to set them.
After that it's one commit after the other that removes or merges things until everything becomes some very simple trait objects
|
|
Indexing is similar to method calls in having an arbitrary
left-hand-side and then something on the right, which is the main part
of the expression. Method calls already have a span for that right part,
but indexing does not. This means that long method chains that use
indexing have really bad spans, especially when the indexing panics and
that span in coverted into a panic location.
This does the same thing as method calls for the AST and HIR, storing an
extra span which is then put into the `fn_span` field in THIR.
|
|
Expand, rename and improve `incorrect_fn_null_checks` lint
This PR,
- firstly, expand the lint by now linting on references
- secondly, it renames the lint `incorrect_fn_null_checks` -> `useless_ptr_null_checks`
- and thirdly it improves the lint by catching `ptr::from_mut`, `ptr::from_ref`, as well as `<*mut _>::cast` and `<*const _>::cast_mut`
Fixes https://github.com/rust-lang/rust/issues/113601
cc ```@est31```
|
|
r=estebank
Avoid wrong code suggesting for attribute macro
Fixes #107113
r? `@estebank`
|
|
|
|
|
|
|
|
|
|
colored and uncolored printing
|
|
|
|
Mark `map_or` as `#[must_use]`
I don't know what else to say.
r? libs
|
|
|
|
Rename and allow `cast_ref_to_mut` lint
This PR is a small subset of https://github.com/rust-lang/rust/pull/112431, that is the renaming of the lint (`cast_ref_to_mut` -> `invalid_reference_casting`).
BUT also temporarily change the default level of the lint from deny-by-default to allow-by-default until https://github.com/rust-lang/rust/pull/112431 is merged.
r? `@Nilstrieb`
|
|
|
|
|
|
|
|
Add `sym::iter_mut` + `sym::as_mut_ptr` for Clippy
We currently have `sym::iter` and `sym::iter_repeat`, this PR adds `sym::iter_mut` as it's useful for https://github.com/rust-lang/rust-clippy/pull/11038 and another Clippy lint, it also adds `sym::as_mut_ptr` as it's useful for https://github.com/rust-lang/rust-clippy/pull/10962.
|
|
Split some functions with many arguments into builder pattern functions
r? `@estebank`
This doesn't resolve all of the ones in rustc, mostly because I need to do other cleanups in order to be able to use some builder derives from crates.io
Works around https://github.com/rust-lang/rust/issues/90672 by making `x test rustfmt --bless` format itself instead of testing that it is formatted
|
|
|
|
|
|
Signed-off-by: David Wood <david@davidtw.co>
|
|
|
|
Implement rust-lang/compiler-team#578.
When an ICE is encountered on nightly releases, the new rustc panic
handler will also write the contents of the backtrace to disk. If any
`delay_span_bug`s are encountered, their backtrace is also added to the
file. The platform and rustc version will also be collected.
|
|
|
|
|
|
|
|
|
|
|
|
Uplift `clippy::fn_null_check` lint
This PR aims at uplifting the `clippy::fn_null_check` lint into rustc.
## `incorrect_fn_null_checks`
(warn-by-default)
The `incorrect_fn_null_checks` lint checks for expression that checks if a function pointer is null.
### Example
```rust
let fn_ptr: fn() = /* somehow obtained nullable function pointer */
if (fn_ptr as *const ()).is_null() { /* ... */ }
```
### Explanation
Function pointers are assumed to be non-null, checking for their nullity is incorrect.
-----
Mostly followed the instructions for uplifting a clippy lint described here: https://github.com/rust-lang/rust/pull/99696#pullrequestreview-1134072751
`@rustbot` label: +I-lang-nominated
r? compiler
|
|
|
|
Nilstrieb:pointer-coercions-are-not-casts-because-that-sounds-way-to-general-aaaa, r=oli-obk
Rename `adjustment::PointerCast` and variants using it to `PointerCoercion`
It makes it sounds like the `ExprKind` and `Rvalue` are supposed to represent all pointer related casts, when in reality their just used to share a little enum variants. Make it clear there these are only coercions and that people who see this and think "why are so many pointer related casts not in these variants" aren't insane.
This enum was added in #59987. I'm not sure whether the variant sharing is actually worth it, but this at least makes it less confusing.
r? oli-obk
|
|
Comments out the C string literals due to https://github.com/rust-lang/rust/pull/113334
Fixes https://github.com/rust-lang/rust-clippy/issues/11121
|
|
It makes it sound like the `ExprKind` and `Rvalue` are supposed to represent all pointer related
casts, when in reality their just used to share a some enum variants. Make it clear there these
are only coercion to make it clear why only some pointer related "casts" are in the enum.
|
|
|
|
|
|
Make simd_shuffle_indices use valtrees
This removes the second-to-last user of the `destructure_mir_constant` query. So in a follow-up we can remove the query and just move the query provider function directly into pretty printing (which is the last user).
cc `@rust-lang/clippy` there's a small functional change, but I think it is correct?
|
