Giters

obi1kenobi / cargo-semver-checks

Scan your Rust crate for semver violations.

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Description and tests for `inherent_method_must_use_added` is not complete

pksunkara opened this issue · comments

commented

Steps to reproduce the bug with the above code

Master branch

Actual Behaviour

Description is An inherent method has been marked with #[must_use].

and the tests only test methods (fn with self)

Expected Behaviour

Follow the same pattern as the other inherent method lints:

Description to change to A method or associated fn has been marked with #[must_use].

And add associated fn tests for this lint.

Generated System Information

master

Build Configuration

No response

Additional Context

No response

commented

None of Rust, rustdoc, or cargo-semver-checks officially distinguish between "associated function" and "method" in any way. All of them are just associated functions, which we all sometimes sloppily call methods as a shorthand. "True associated fn" tests for this lint would be nice but realistically won't catch anything that won't already be caught otherwise.

Would you be open to making a PR with the changes you proposed? I'd be happy to merge it!

commented

None of Rust, rustdoc, or cargo-semver-checks officially distinguish between "associated function" and "method" in any way.

I think the docs do differentiate between them.

From https://doc.rust-lang.org/book/ch05-03-method-syntax.html

methods are defined within the context of a struct (or an enum or a trait object), and their first parameter is always self

All functions defined within an impl block are called associated functions

IIRC, all the other lints do use the associated fn in description except for this one.

I would suggest tagging this issue as a starter one and see if any new contributor wants to pick this one up since it's an easy one. I will pick it up if it's still open in a few months.

commented

It's not worth keeping this issue open for months. I'd like to either quickly merge some PRs for it or close it as not-planned, because open issues cost me triage time every time I go through them.

The tests you suggested would be a tiny nice-to-have, as in I'd merge a PR you open for it but I wouldn't write it myself because that's extremely unlikely to ever break. The methods definition you point to is purely user-facing convention, and doesn't map to any abstraction that rustc or rustdoc includes.

For the associated fn description suggestion, I'd either merge your PR (if you'd like to open one) or make one myself to make it say An inherent method or associated fn has been marked #[must_use]. Again, it's easier to make the PR than to keep an open issue for months for a 10-second fix.