Fix missing_inline_in_public_items fail to fulfill expect in --test build

[profetia]

Closes #13394

changelog: [missing_inline_in_public_items] fix failure to fulfill expect in --test build

[rustbot]

r? @y21

rustbot has assigned @y21.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[y21]

This does mean that something like #[expect(clippy::missing_inline_in_public_items)] fn private_function() {} passes the expectation with --test even though the lint would never emit a warning there, but I'm not really sure how we could avoid that so this seems fine

[Alexendoo]

This looks like a symptom rather than the root of the issue, that the following is a false negative when ran with cargo clippy --tests

#![warn(clippy::missing_inline_in_public_items)]

pub fn foo() -> u32 {
    0
}

It should still lint foo as it would for cargo clippy

[profetia]

Hmm.. Im confused. What is the expected behavior in --test ?

[profetia]

I doubt if it is possible to know the original crate type in --test

[profetia]

r? clippy

[Alexendoo]

I doubt if it is possible to know the original crate type in --test

Yeah I think that might well be the case

Something we could do is remove the is_executable_or_proc_macro check entirely, it would be a useless warning for bin crates but as it's a restriction lint that should be okay

[profetia]

Updated. Check for executables are now removed

[github-actions]

Lintcheck changes for 33a5d5e

Lint	Added	Removed	Changed
clippy::missing_inline_in_public_items	10	0	0

This comment will be updated if you push new changes

[profetia]

r? clippy

[profetia]

r? clippy

[Centri3]

I'll think about this more tomorrow. One concern for now

View changes since this review

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

[Centri3]

I think I'm +1 on linting in binary crates. It makes sense to me to still lint as maybe they'd extract it into a library crate in the future. The only file this doesn't make sense in is main.rs.

This does mean that something like #[expect(clippy::missing_inline_in_public_items)] fn private_function() {} passes the expectation with --test even though the lint would never emit a warning there, but I'm not really sure how we could avoid that so this seems fine

Just to confirm, is this no longer an issue with the new implementation? Is this just something that happens with some lints?

[profetia]

Yes, this is no longer a issue. A private function with such expect will also fail when its in --test