Add #[must_use] to cargo new --lib example code

[tyilo]

What does this PR try to resolve?

This adds the #[must_use] attribute to the example lib code so that cargo clippy -- -Wclippy::pedantic doesn't emit any lints.

Before this change, clippy::must_use_candidate is emitted.

How to test and review this PR?

Run cargo new --lib and cargo clippy -- -Wclippy::pedantic and see that clippy::must_use_candidate is no longer emitted.

[rustbot]

r? @epage

rustbot has assigned @epage.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

• Owners of files modified in this PR: @ehuss, @epage, @weihanglo
• @ehuss, @epage, @weihanglo expanded to ehuss, epage, weihanglo
• Random selection from ehuss, epage, weihanglo

[weihanglo]

I don't think this is the only warning you got when running clippy with -Wclippy::pedantic. We have deliberately scoped clippy lints to a subset. We normally don't accept unless there is some compelling reason, for example:

• refactor: clean up clippy::perf lint warnings #15631
• Migrate Cargo's &Option<T> into Option<&T> #14609
• replace !Vec::is_empty() then Some(Vec) with bool::then() #14516
• fix clippy warnings #12050

Would you mind share the reason motivating you to open this PR (and only with this lint fixed)? Otherwise I tend to close this. Thank you.

[tyilo]

It is the only lint.

[epage]

While this is might be the only lint in the generated code, I think the approach we take to lints in Cargo is relevant.

It is also not clear why this matters. These are pedantic (non-default) lints for code that will be deleted.

[tyilo]

While this is might be the only lint in the generated code, I think the approach we take to lints in Cargo is relevant.

Ah, I understand what @weihanglo meant now. I was only talking about the generated code.

It is also not clear why this matters. These are pedantic (non-default) lints for code that will be deleted.

I think the generated example code should be as idiomatic as possible, even if it will be deleted.

But I also understand why this isn't important enough to change. Feel free to close the PR.

[epage]

I think the generated example code should be as idiomatic as possible, even if it will be deleted.

If this is something considered idiomatic, I'd want to better understand why it is relegated to a pedantic lint.

[tyilo]

If this is something considered idiomatic, I'd want to better understand why it is relegated to a pedantic lint.

Well its on Add::add in the standard library and this function implements the same functionality:

#[must_use = "this returns the result of the operation, without modifying the original"]

It is a pedantic lint because it has a lot of false positives, but in this specific case the function should have a #[must_use] attribute. See "Known problems" here: https://rust-lang.github.io/rust-clippy/master/#must_use_candidate

[arlosi]

Thanks for the suggestion, but we're very conservative with changes to examples generated by cargo new. In the lib case, users will immediately delete the add function anyway, and it's a slippery slope of what idiomatic/best practices to include in the cargo new template.

#5151 tracks implementation of a templating system for users to be able to customize it to their needs.