Add utility macros to help with writing tests.
Adds two utility macros to help with testing:
* `external` expands to it's argument tokens, but makes them appear to come from an external macro. Helps make tests for `in_external_macro` much more readable.
* `inline_macros` is an attribute macro which allows the use of a pseudo `inline!` macro which expands to it's argument tokens, but makes them appear to be from a crate-local macro expansion. This removes the need to write `macro_rules` boilerplate when testing how lints interact with macros.
---
`external`'s usage is simple. `external!(struct Foo { x: u32});` will make the struct appear as though it came from an external macro. Individual tokens can be escaped if needed. `external!($x + 0 / 10)` will make everything except `x` appear as though it came from an external macro. Can also use `$literal` and `$(tokens...)` as well.
---
`inline_macros` is more complicated due to compiler constraints. Given:
```rust
#[inline_macros]
fn foo() {
inline!(5 + 5 / 10);
}
```
`inline!(5 + 5 / 10)` will be replace with a call to a generated macro which expands to the contained tokens.
Tokens can be escaped by prefixing them with `$`:
```rust
#[inline_macros]
fn foo() {
let x = 5;
inline!($x + 5 / $10);
}
```
This will pass `x` as an `ident` argument and `10` as a `literal` argument.
Token sequences can also be passed with `$(...)`:
```rust
#[inline_macros]
fn foo() {
let mut x = 5;
inline!(if $(x >= 5) {
$x = 5;
});
}
```
This will pass `x >= 5` as `tt` arguments, and `x` as an `ident` argument.
---
Not 100% sure `inline_macros` is actually worth having. It does make the tests a little easier to read once you're used to it and it becomes more useful once there are multiple macro tests. The verbosity of declaring single use macros starts to hurt at that point.
changelog: None
Improve diagnostic of `no_mangle_with_rust_abi`
fixes#10409
Pending rust-lang/rustfmt#5701
This rewords the message to focus on the error being an implicit ABI, rather than the `Rust` ABI. Also downgrades the suggestion to `MaybeIncorrect` and changes the suggestion span to better highlight the change.
---
changelog: None
<!-- changelog_checked -->
Directly construct Inherited in typeck.
Using `InheritedBuilder` + a closure does not seem necessary any more.
+ a few opportunistic simplifications to typeck entry point.
Add more license annotations
This PR updates the `.reuse/dep5` file to include more accurate licensing data for everything in the repository (*excluding* submodules and dependencies). Some decisions were made in this PR:
* The standard copyright attribution for files maintained by us is "The Rust Project Developers (see https://thanks.rust-lang.org)", to avoid having to maintain an in-tree `AUTHORS` file.
* For files that have specific licensing terms, we added the terms to the `.reuse/dep5` rather than adding SPDX comments in the files themselves.
* REUSE picks up any comment/text line with `Copyright` on it, so I had to sprinkle around `REUSE-IgnoreStart` and `REUSE-IgnoreEnd` comments.
The rendered `COPYRIGHT` file is available at https://gist.github.com/pietroalbini/efb81103f69596d39758114f3f6a8688.
r? `@pnkfelix`
Don't lint `manual_clamp` in const contexts.
fixes#10474
Probably worth including in the sync.
r? `@flip1995`
changelog: [`manual_clamp`]: Don't lint in const contexts.
Migrate `write.rs` to `rustc_ast::FormatArgs`
changelog: none
Part 1 of #10233
The additions to `clippy_utils` are the main novelty of this PR, there's no removals yet since other parts still rely on `FormatArgsExpn`
The changes to `write.rs` itself are relatively straightforward this time around, as there's no lints in it that rely on type checking format params
r? `@flip1995`
Mark Rust 1.68.0 as release in the changelog
Roses are red,
this poem is dead,
my creativity is lost,
outside there is frost?
Maybe I should really stop including a "roses are red" with every changelog PR. These are getting worse every time...
---
changelog: none
<!-- changelog_checked -->
Include async functions in the len_without_is_empty
fixes#7232
Changes done to the functionality:
Allowing different error types for the functions was disallowed. So the following was linted before but is not after this change
```
impl Foo {
pub len(&self) -> Result<usize, Error1> { todo!(); }
pub is_empty(&self) -> Result<bool, Error2> { todo!(); }
}
```
---
changelog: Enhancement: [`len_without_is_empty`]: Now also detects `async` functions
[#10359](https://github.com/rust-lang/rust-clippy/pull/10359)
<!-- changelog_checked -->
[arithmetic_side_effects] Fix#10252Fix#10252
At least for integers, shifts are already handled by the compiler.
----
changelog: [`arithmetic_side_effects`]: No longer lints on right or left shifts with constant integers, as the compiler warns about them.
[#10309](https://github.com/rust-lang/rust-clippy/pull/10309)
<!-- changelog_checked-->
Rollup of 8 pull requests
Successful merges:
- #108754 (Retry `pred_known_to_hold_modulo_regions` with fulfillment if ambiguous)
- #108759 (1.41.1 supported 32-bit Apple targets)
- #108839 (Canonicalize root var when making response from new solver)
- #108856 (Remove DropAndReplace terminator)
- #108882 (Tweak E0740)
- #108898 (Set `LIBC_CHECK_CFG=1` when building Rust code in bootstrap)
- #108911 (Improve rustdoc-gui/tester.js code a bit)
- #108916 (Remove an unused return value in `rustc_hir_typeck`)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
This was previously needed because the indirection used to hide some unexplained lifetime errors, which it turned out were related to the `min_choice` algorithm.
Removing the indirection also solves a couple of cycle errors, large moves and makes async blocks support the `#[track_caller]` annotation.
Add the `popular-crates` binary
This program downloads crates info from <https://crates.io/> and builds a TOML file that can be fed to `lintcheck`.
I have been asked, on various pull requests, what the result of `lintcheck` was. However, the default configuration file for lintcheck is limited. This `popular-crates` program allows building a recent list of the recently most downloaded crates from <https://crates.io> and feed it to `lintcheck`. Using it, it was easy to test two new lints against the 500 recently most downloaded crates to ensure that there was no regression.
changelog: none
