Fix missing_inline_in_public_items fail to fulfill expect in --test build
#15320
Conversation
rustbot
added
the
S-waiting-on-review
There was a problem hiding this comment.
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
|
|
||
| if is_executable_or_proc_macro(cx) | ||
| // Allow the lint if it is expected, when building with `--test` | ||
| && !(cx.sess().is_test_crate() && lint_is_expected(cx, it.owner_id, MISSING_INLINE_IN_PUBLIC_ITEMS)) |
There was a problem hiding this comment.
Could this use clippy_utils::fulfill_or_allowed? Then it wouldn't need the new util function. The existing one will return true for #[allow] but I don't think that makes a difference
| #![crate_type = "dylib"] | ||
| // When denying at the crate level, be sure to not get random warnings from the | ||
| // injected intrinsics by the compiler. | ||
| #![allow(dead_code)] |
There was a problem hiding this comment.
Are these two attributes necessary? I'm pretty sure they're both implicitly set. At least for me it passes just fine without them
|
This looks like a symptom rather than the root of the issue, that the following is a false negative when ran with #![warn(clippy::missing_inline_in_public_items)]
pub fn foo() -> u32 {
0
}It should still lint |
|
Hmm.. Im confused. What is the expected behavior in |
Closes #13394
changelog: [
missing_inline_in_public_items] fix failure to fulfillexpectin--testbuild