New lint: `path_attribute`

What it does

Warns when the built-in #[path = "..."] attribute is used to override the source file of an out-of-line module.

Advantage

• Using Rust's conventional module file layout makes the relationship between module names and source files predictable for readers and tooling.

Drawbacks

#[path] is useful for generated code, platform-specific implementations, tests, and projects with non-standard source layouts. This lint would therefore belong to the restriction group and remain allow-by-default.

Example

#[path = "implementation.rs"]
mod parser;

Could be written as:

mod parser;

with the implementation moved to parser.rs or parser/mod.rs.

Comparison with existing lints

Unlike self_named_module_files, mod_module_files, and inline_modules, this lint specifically detects use of the built-in #[path] attribute.
None of those lints prohibit overriding a module's source path.

Additional Context

This is useful for projects that enforce a conventional module layout in CI.
For example, in AI-assisted development workflows, generated patches may introduce #[path] even when the conventional layout would work.

Natural-language or contributor guidelines can discourage the pattern, but cannot enforce it across every change path.
An allow-by-default restriction lint provides a machine-enforceable policy.

A more general alternative would be a configurable disallowed_attributes lint analogous to disallowed_methods, disallowed_types, and disallowed_macros.
If that is preferable to a dedicated path_attribute lint, it would also address this use case.

Start by reviewing the existing self_named_module_files, mod_module_files, and inline_modules lints and the proposal's disallowed_attributes alternative. Determine whether the change should be a dedicated path_attribute lint or a configurable mechanism, then verify that the selected approach warns on out-of-line modules using #[path] while remaining allow-by-default.