missing_inline_in_public_items is unreliable in proc macro crates

Summary

When the missing_inline_in_public_items lint is enabled in a proc macro crate, if the exported proc macro fn item is not annotated with #[inline], the lint triggers sometimes but not always. In my case, rust-analyzer for VSCode does show the lint being triggered, but the CLI does not.

Lint Name

missing_inline_in_public_items

Reproducer

I tried this code:

#![deny(clippy::missing_inline_in_public_items)]

use proc_macro::TokenStream;

#[proc_macro_derive(Error, attributes(display))]
pub fn impl_error(input: TokenStream) -> TokenStream {
    input
}

...in a proc macro crate:

[package]
name = "rust-playground"
version = "0.1.0"
edition = "2024"

[lib]
proc-macro = true

[dependencies]

I got this output from the CLI (no errors):

➜  rust-playground git:(master) ✗ cargo clippy
    Checking rust-playground v0.1.0 (/Users/luisferlcc/rust-playground)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.13s

...but this output from rust-analyzer (error):

I expected to see the same result from the CLI and from rust-analyzer, preferably that neither trigger the lint, since #[inline] doesn't make much sense for a proc macro.

Version

rustc 1.93.0 (254b59607 2026-01-19)
binary: rustc
commit-hash: 254b59607d4417e9dffbc307138ae5c86280fe4c
commit-date: 2026-01-19
host: aarch64-apple-darwin
release: 1.93.0
LLVM version: 21.1.8

Additional Labels

@rustbot label +L-restriction

@rustbot label +T-macros

Start by reproducing the missing_inline_in_public_items behavior in the proc-macro crate shown in the issue, comparing cargo clippy with rust-analyzer. Trace the lint's handling of the exported proc macro function and verify that the CLI and rust-analyzer produce the agreed result, including the expected treatment of #[inline].