Lints cannot be silenced / denied without going through hoops

[BD103]

#[allow(bevy::main_return_without_appexit)], -A bevy::main_return_without_appexit, and adding main_return_without_appexit = "allow" to Cargo.toml all fail.

See Discord for original report.

[janhohenheim]

Changed the title because the silencing works after adding #![feature(register_tool)] on nightly. It's just not an ideal situation to be in.

[BD103]

Did a bit of digging into this.

• #![register_tool(...)] Tracking issue
• Initial implementation
• The registered_tools() method
• Zulip message about registering tools from codegen

In summary, while it could be possible to automatically register the bevy tool namespace from bevy_lint_driver, it would cause errors when not running the linter because the namespace would not be registered in those cases. (And, the only way I can think of registering from codegen is breaking Rust's exclusive mutability rules, so not a good idea.)

[BD103]

I think we should just document how to use #![register_tool(...)], and recommend putting it behind a cfg flag.

[janhohenheim]

Could you elaborate on the cfg? What kind of flag would that be and who passes it when?

[BD103]

I was thinking we encourage users to add this to their crate root:

#![cfg_attr(bevy_lint, feature(register_tool), register_tool(bevy))]

And this to their Cargo.toml:

[lints.rust]
unexpected_cfgs = { level = "warn", check-cfg = ["cfg(bevy_lint)"] }

And bevy_lint would pass --cfg bevy_lint to bevy_lint_driver.

But that wouldn't work because register_tool(...) is only available on nightly, so cargo check would still fail with the "unexpected tool name bevy" error on stable Rust.

If we really want to do this, our best course of action is probably getting #![register_tool(...)] stabilized.

[BD103]

I'm going to close this as not planned. The RFC is way too far off in the horizon, and the hoops are an unfortunate fact of that. #117 will stand in as a temporary solution until then.