EarlyLintPass::check_mac() is not called in non-toplevel modules

[rhysd]

Environment

• cargo clippy -V: clippy 0.0.212 (d4092ace 2020-05-11)
• OS: macOS 10.14

Repro

1. Run cargo new foo
2. Put src/main.rs and src/nested.rs as follows
3. Run cargo clippy

• main.rs

#![warn(clippy::print_stdout)]
#![warn(clippy::dbg_macro)]

mod nested;

fn main() {
    dbg!("hi");
    println!("Hello, world!");
    nested::bye();
}

• nested.rs

pub fn bye() {
    dbg!("bye");
    println!("bye bye");
}

Expected behavior

cargo clippy causes 4 warnings; 2 print_stdout warnings and 2 dbg_macro warnings, 2 caused in main.rs and 2 caused in nested.rs.

Actual behavior

cargo clippy causes 2 warnings; 1 print_stdout warning and 1 dbg_macro warning, 2 caused in main.rs. No warning is detected in nested.rs.

Output:

warning: `dbg!` macro is intended as a debugging tool
 --> src/main.rs:7:5
  |
7 |     dbg!("hi");
  |     ^^^^^^^^^^
  |
note: the lint level is defined here
 --> src/main.rs:2:9
  |
2 | #![warn(clippy::dbg_macro)]
  |         ^^^^^^^^^^^^^^^^^
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#dbg_macro
help: ensure to avoid having uses of it in version control
  |
7 |     "hi";
  |     ^^^^

warning: use of `println!`
 --> src/main.rs:8:5
  |
8 |     println!("Hello, world!");
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^
  |
note: the lint level is defined here
 --> src/main.rs:1:9
  |
1 | #![warn(clippy::print_stdout)]
  |         ^^^^^^^^^^^^^^^^^^^^
  = help: for further information visit https://rust-lang.github.io/rust-clippy/master/index.html#print_stdout

warning: 2 warnings emitted

    Finished dev [unoptimized + debuginfo] target(s) in 0.00s

Investigation

Both print_stdout and dbg_macro rules are using EarlyLintPass::check_mac method. It seems that check_mac is only called on toplevel module (lib.rs or main.rs).

[repi]

We were testing the print_stdout and print_stderr in our codebases and think ran into this issue also of the lint being ineffective due to not really running on most of our code. Our hope was to find stray println! somewhere deep down in our modules but wasn't caught