Summary
It seams the lint just does a plaintext search and therefor catches #[test] even inside of macros i.e. when it is not actually annotating a test function.
Examples for macros that trigger but shouldn't: stringify!, quote::quote!, syn::parse_quote!, ... probably makes sense to just disable the lint whenever it is inside a macro.
Lint Name
test_attr_in_doctest
Reproducer
I tried this code:
#[warn(clippy::pedantic)]
/// ```
/// assert_eq!(stringify!(#[test]), "#[test]");
/// ```
pub struct Test;
I saw this happen:
warning: unit tests in doctest are not executed
--> src/lib.rs:4:27
|
4 | /// assert_eq!(stringify!(#[test]), "#[test]");
| ^^^^^^^
|
= help: for further information visit https://rust-lang.github.io/rust-clippy/rust-1.98.0/index.html#test_attr_in_doctest
= note: `#[warn(clippy::test_attr_in_doctest)]` on by default
I expected to see this happen:
No lint emitted, as #[test] is not actually annotating a test function.
Version
cargo 1.98.1 (797e8a9bc 2026-08-05)
release: 1.98.1
commit-hash: 797e8a9bca276c1c9f9f738d2a20f484fa4eea9d
commit-date: 2026-08-05
host: x86_64-unknown-linux-gnu
libgit2: 1.9.4 (sys:0.21.0 vendored)
libcurl: 8.21.0-DEV (sys:0.4.90+curl-8.21.0 vendored ssl:OpenSSL/3.6.3)
ssl: OpenSSL 3.6.3 9 Jun 2026
os: Arch Linux Rolling Release [64-bit]
Additional Labels
No response
Summary
It seams the lint just does a plaintext search and therefor catches
#[test]even inside of macros i.e. when it is not actually annotating a test function.Examples for macros that trigger but shouldn't:
stringify!,quote::quote!,syn::parse_quote!, ... probably makes sense to just disable the lint whenever it is inside a macro.Lint Name
test_attr_in_doctest
Reproducer
I tried this code:
I saw this happen:
I expected to see this happen:
No lint emitted, as
#[test]is not actually annotating a test function.Version
Additional Labels
No response