-
-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
New test crate: method moved to trait #[must_use]
added
#282
New test crate: method moved to trait #[must_use]
added
#282
Conversation
This was converted to draft because of the problem mentioned here #283 (comment) (enums & unions also can have methods, this test crate only contains struct tests). I would like to add similar tests for the two missing types once |
Either way is fine by me. As a hybrid option, you could split the structs / enums / unions test cases into different files in the same test crate, which will make the overall structure simpler to review while keeping these conceptually-related tests in the same crate and PR. |
Check out #290 for something else that's good to add to new test crates: just a little safeguard against an erroneous |
The purpose of this test crate
is to avoid duplicate lints. In this crate, there could be reports about both #[must_use] being added to the methods, as well as the methods themselves being moved to a
Trait
. Because both of these are minor changes, and the#[must_use]
added violation is impossible to achieve here without themethod_moved_to_trait
check failing, we want the#[must_use]
checks to not find any changes, but expect a failure on themethod_moved_to_trait
check.From the
#[must_use]
attribute addition point of view:This test crate mainly contains cases where a breaking change happens:
Foo
is a public, inherent method of a public Struct, with or without the#[must_use]
attribute,Foo
is moved to a public Trait, with addition, deletion or change of the#[must_use]
attribute inside the Trait.There ale also selective test cases where the change is not breaking:
#[must_use]
modification takes place inside animpl Trait for Struct
block, (1)(1) - this is a separate test case because such addition does not actually cause the compiler to give a warning when the return value is not used. Only the
#[must_use]
attribute modifications that are done inside the Trait affect it, thus these are technically non-breaking and were separated into their own test case.From the
method_moved_to_trait
point of view:Once the lint is implemented, all of the test cases should be reported except for: