New test crate: method moved to trait #[must_use] added

[SmolSir]

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 the method_moved_to_trait check failing, we want the #[must_use] checks to not find any changes, but expect a failure on the method_moved_to_trait check.

From the #[must_use] attribute addition point of view:

This test crate mainly contains cases where a breaking change happens:

• in the old version, the method Foo is a public, inherent method of a public Struct, with or without the #[must_use] attribute,
• in the new version, the method 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:

• the same scenario as above, but with private Struct & Trait,
• the same scenario as above, but the attribute is not present inside the Trait; instead #[must_use] modification takes place inside an impl Trait for Struct block, (1)
• adding a new public Trait that implements a new public Struct (both are not present in the old crate version).

(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:

• the private Struct & Trait scenario from above,
• adding a new public Trait that implements a new public Struct (both are not present in the old crate version).

[SmolSir]

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 Union is added to the schema. Should I split the PR into smaller per-type PRs with smaller crates to allow faster, smaller merges, or just add the missing types here?

[obi1kenobi]

Should I split the PR into smaller per-type PRs with smaller crates to allow faster, smaller merges, or just add the missing types here?

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.

[obi1kenobi]

Check out #290 for something else that's good to add to new test crates: just a little safeguard against an erroneous cargo publish accidentally publishing them to crates.io.