needless arbitrary self: handle macros
This fixes two cases related to macros:
* If the parameter comes from expansion, do not lint as the user has no possibility of changing it. This is not directly related to the fixed issue, but we should probably do that.
* If *only* the lifetime name comes from expansion, lint, but allow the user decide the name of the lifetime. In the related issue, the lifetime was unnamed and then renamed by `async_trait`, so just removing the name in the suggestion would work, but in the general case a macro can rename a lifetime that was named differently, and we can't reliably know that name anymore.
As a hint for the reviewer, the expanded code for the test can be checked with this command (from the root dir of the repo):
```sh
rustc -L target/debug/test_build_base/needless_arbitrary_self_type_unfixable.stage-id.aux -Zunpretty=expanded tests/ui/needless_arbitrary_self_type_unfixable.rs
```
changelog: [`needless_arbitrary_self_type`]: handle macros
Fixes#6089
Add option to pass a custom codegen backend from a driver
This allows the driver to pass information to the codegen backend. For example the headcrab debugger may in the future want to use cg_clif to JIT code to be injected in the debuggee. This would PR make it possible to tell cg_clif which symbol can be found at which address and to tell it to inject the JITed code into the right process.
This PR may also help with https://github.com/rust-lang/miri/pull/1540 by allowing miri to provide a codegen backend that only emits metadata and doesn't perform any codegen.
cc @nbaksalyar (headcrab)
cc @RalfJung (miri)
New Lint: disallowed_method
Fixes https://github.com/rust-lang/rust-clippy/issues/6073
I added a `disallowed_method` lint that works similar to `blacklisted_name`, e.g allows config-defined disallowed method calls.
This lint allows advanced users to patch in undesired method calls for specific projects. It basically uses the DefId of method calls and matches it to parsed strings. Is there an alternative approach that could use more easily digestible configuration strings?
All tests pass as expected except for a linting error on `ui/redundant_pattern_matching_option`, which I am not sure how to resolve since I don't think I changed anything affecting it.
changelog: Add disallowed_method lint to warn on user-defined method calls
Fix FP in `print_stdout`
Fix#6041
This lint shouldn't be emitted in `build.rs` as `println!` and `print!` are used for the build script.
changelog: none
UI tests cleanup
`@matthiaskrgr` noticed some `run-pass` annotations in some crash tests that were added in #3922. At that moment they seemed to be necessary to make the tests fail in case of an ICE, but they do not seem to be needed anymore. To test this I forced an ICE in a file with and without annotations, with and without stderr files, and the ICE makes the test fail every time.
In addition, I've applied a suggestion from `@ehuss` and `@jyn514` to add `emit=metadata` to the rustc flags for the UI tests. In my machine this improved the run time from ~17 to ~12 seconds.
changelog: none
Update Clippy
Bi-weekly Clippy update.
This includes a `Cargo.lock` update (d445493479711389f4dea3a0f433041077ba2088), so probably needs `rollup=never`.
r? `@Manishearth`
Allow a unique name to be assigned to dataflow graphviz output
Previously, if the same analysis were invoked multiple times in a single compilation session, the graphviz output for later runs would overwrite that of previous runs. Allow callers to add a unique identifier to each run so this can be avoided.
Revert: or_fun_call should lint calls to `const fn`s with no args
The changes in #5889 and #5984 were done under the incorrect assumption that a `const fn` with no args was guaranteed to be evaluated at compile time. A `const fn` is only guaranteed to be evaluated at compile time if it's inside a const context (the initializer of a `const` or a `static`).
See this [zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Common.20misconception.3A.20.60const.20fn.60.20and.20its.20effect.20on.20codegen/near/208059113) for more details on this common misconception.
Given that none of the linted methods by `or_fun_call` can be called in const contexts, the lint should make no exceptions.
changelog: [`or_fun_call`] lints again calls to `const fn` with no args
Fix a FP in `explicit_counter_loop`
Fixes#4677 and #6074
Fix a false positive in `explicit_counter_loop` where the loop counter is used after incremented, adjust the test so that counters are incremented at the end of the loop and add the test for this false positive.
---
changelog: Fix a false positive in `explicit_counter_loop` where the loop counter is used after incremented
Add `rc_buffer` lint for checking Rc<String> and friends
Fixes#2623
This is a bit different from the original PR attempting to implement this type of lint. Rather than linting against converting into the unwanted types, this PR lints against declaring the unwanted type in a struct or function definition.
I'm reasonably happy with what I have here, although I used the fully qualified type names for the Path and OsString suggestions, and I'm not sure if I should have just used the short versions instead, even if they might not have been declared via use.
Also, I don't know if "buffer type" is the best way to put it or not. Alternatively I could call it a "growable type" or "growable buffer type", but I was thinking of PathBuf when I started making the lint.
changelog: Add `rc_buffer` lint
Fix a false positive in `explicit_counter_loop` where the loop counter is used after incremented,
adjust the test so that counters are incremented at the end of the loop
and add the test for this false positive.
