(Small) Fix broken links for Rust merge
rust-lang/rust#110003's CI is [currently broken](https://github.com/rust-lang/rust/actions/runs/4628510374/jobs/8187672234?pr=110003) because of broken links. This PR fixes that.
It was tested against `lintcheck` and found another broken link in `usage.md` (apart from CI's broken links)
changelog:Fix broken links in the book
Sorry for putting more work on you, but you're the one doing the Rust PR
r? `@flip1995`
new lint: suspicious_doc_comments
Fixes#10485.
This PR adds a new lint (`suspicious_doc_comments`) that triggers when the user writes `///!` or `/**!`.
This is almost certainly a mistake and the user probably meant to write an inner doc comment (`//!`, `/*!`) to document the module or crate that this comment is contained in.
changelog: [`suspicious_doc_comments`]: new lint
fix `single_component_path_imports` FP on `self::<import>::..`
fixes#10549
I noticed that a couple functions in the file I was working on took `cx` as a parameter but didn't use them, so I removed that. Can revert if desired because it isn't related to my changes.
changelog: [`single_component_path_imports`] don't suggest removing import when it is used as `self::<import>::..`
fix [`mem_replace_option_with_none`] not considering field variables
fixes: #9824
---
changelog: fix [`mem_replace_option_with_none`] not considering field variables
Make redundant_async_block a more complete late pass
This lets us detect more complex situations: `async { x.await }` is simplified into `x` if:
- `x` is an expression without side-effect
- or `x` is an `async` block itself
In both cases, no part of the `async` expression can be part of a macro expansion.
Fixes#10509.
Fixes#10525.
changelog: [`redundant_async_block`] Do not lint expressions with side effects.
This lets us detect more complex situations: `async { x.await }` is
simplified into `x` if:
- `x` is an expression without side-effect
- or `x` is an async block itself
In both cases, no part of the `async` expression can be part of a macro
expansion.
Add `tests_outside_test_module` lint
Adds `tests_outside_test_module` from #10506. This PR **doesn't** close the issue, just resolves task 1.
changelog: [`tests_outside_test_module`]: The lint has been added
Fix bug with getting parent directories in `lookup_conf_file`
Currently `lookup_conf_file` doesn't canonicalize the configuration directory before using [`PathBuf::pop`](https://doc.rust-lang.org/std/path/struct.PathBuf.html#method.pop) to get the parent directory. This isn't usually an issue when clippy is invoked via `cargo clippy` as `CARGO_MANIFEST_DIR` is already canonicalized. However, this currently causes `clippy-driver` to ignore any `clippy.toml` in any parent directories when `CARGO_MANIFEST_DIR` and `CLIPPY_CONF_DIR` are not set.
changelog: Fix a bug that would cause parent directories not to be searched for `clippy.toml` when using `clippy-driver` directly.
Mini-fix `double_must_use` for async functions
From Rust 1.67 onwards, the `#[must_use]` attribute also applies to the `Future::Output` (rust-lang/rust#100633). So the lint `double_must_use` was linting all async functions. This PR changes the `double_must_use` lint so it ignores `async` functions.
---
Closes#10486
changelog: [`double_must_use`]: Fix false positive in async function
Show multiple clippy.toml warnings with `sess.warn` instead of `eprintln!`
Use `sess.warn` to display the multiple clippy.toml warning instead of `eprintln!`.
changelog: none
Document `cargo-clippy` feature
It is possible to use conditional compilation to prevent Clippy from evaluating certain code at all. Unfortunately, it was no longer documented anywhere. This adds a brief explanation of how to use the feature with conditional compilation, and mentions a few downsides.
Fixes#10220 — Ability to skip files or blocks entirely
changelog: none
<!-- changelog_checked -->
Update subtree sync docs for changes in rustc-dev-guide
Companion PR to https://github.com/rust-lang/rustc-dev-guide/pull/1653. That still keeps a `contributing.html` with an "External Contributions" section, so hopefully it won't be too disruptive.
changelog: none
Partial no-op refactoring of #9948
This contains some prep work for #9948 to keep that change to the minimum, and make it easier to review it.
This should be a noop, but it has some tests from that PR discussion, and should help in the future with the corner case format handling.
cc: `@Alexendoo` `@llogiq` `@xFrednet` as the 3 people who reviewed the parent PR
----
changelog: none
[arithmetic_side_effects] Fix#10583Fixes#10583
```
changelog: [`arithmetic_side_effects`]: Correctly handle division and module when the right-hand-side is unknown
```
Initial support for return type notation (RTN)
See: https://smallcultfollowing.com/babysteps/blog/2023/02/13/return-type-notation-send-bounds-part-2/
1. Only supports `T: Trait<method(): Send>` style bounds, not `<T as Trait>::method(): Send`. Checking validity and injecting an implicit binder for all of the late-bound method generics is harder to do for the latter.
* I'd add this in a follow-up.
3. ~Doesn't support RTN in general type position, i.e. no `let x: <T as Trait>::method() = ...`~
* I don't think we actually want this.
5. Doesn't add syntax for "eliding" the function args -- i.e. for now, we write `method(): Send` instead of `method(..): Send`.
* May be a hazard if we try to add it in the future. I'll probably add it in a follow-up later, with a structured suggestion to change `method()` to `method(..)` once we add it.
7. ~I'm not in love with the feature gate name 😺~
* I renamed it to `return_type_notation` ✔️
Follow-up PRs will probably add support for `where T::method(): Send` bounds. I'm not sure if we ever want to support return-type-notation in arbitrary type positions. I may also make the bounds require `..` in the args list later.
r? `@ghost`
Add suggestions to `extra_unused_type_parameters`
Change the `extra_unused_type_parameters` lint to provide machine applicable suggestions rather than just help messages. Exception to this are cases when any unused type parameters appear bounded in where clauses - for now I've deemed these cases unfixable and separated them out. Future work might be able to provide suggestions in these cases.
Also, added a test case for the `avoid_breaking_exported_api` config option.
r? `@flip1995`
changelog: [`extra_unused_type_parameters`]: Now provides fixable suggestions.
Insert alignment checks for pointer dereferences when debug assertions are enabled
Closes https://github.com/rust-lang/rust/issues/54915
- [x] Jake tells me this sounds like a place to use `MirPatch`, but I can't figure out how to insert a new basic block with a new terminator in the middle of an existing basic block, using `MirPatch`. (if nobody else backs up this point I'm checking this as "not actually a good idea" because the code looks pretty clean to me after rearranging it a bit)
- [x] Using `CastKind::PointerExposeAddress` is definitely wrong, we don't want to expose. Calling a function to get the pointer address seems quite excessive. ~I'll see if I can add a new `CastKind`.~ `CastKind::Transmute` to the rescue!
- [x] Implement a more helpful panic message like slice bounds checking.
r? `@oli-obk`
