Embark standard lints v0.3

[repi]

Current plan for v0.3

• Add: map_err_ignore - prevents loosing error context and works well in Ark, easy to ignore when needed
• Add: match_same_arms - seems to work well and simplifies matching code to reduce complexity, with some exceptions.
• Add: large_types_passed_by_value - seems like a good idea, could catch some things should be boxed. no warns in Ark.
• Add: string_add - cleaner & more explicit, only 1 easy fixed warn in Ark.
• Add: string_add_assign - cleaner & more explicit, only 1 easy fixed warn in Ark.
• Add: explicit_iter_loop - we already use explicit_into_iter_loop in v0.2, should enable or disable both.
• Add: unimplemented - good for stubbing out WIP code but want to avoid on main our crates & systems are live at head

The match_same_arms lint is definitely the most intrusive change of these, and may need some opt outs in a few cases when one doesn't want to re-order code, but have been quite favored still.

Under consideration, but currently not in v0.3

Some discussion in the PR but think these require more testing or follow up.

• Add: needless_pass_by_value - helped us catch a lot of unnecessary : Vec<T> arguments and replace them with : &[T], saving a lot of calls to .clone() (very common trap for rust beginners to fall into). quite intrusive change for lots of crates though so safer to do separtely
• Remove: doc_markdown - has a 4y old outstanding issue on acronyms that it wants to force codeformatting backticks on which is quite messy and requires a lot of manual disabling (or a clippy.toml config): doc_markdown should ignore things which just contain acronyms rust-lang/rust-clippy#1136
• Remove: pub_enum_variant_names - pretty common for this one to trigger in valid/good cases, so is a bit hit & miss.
• Remove: suboptimal_flops - rearranges code quite significantly with mul_add

Will leave this as a draft for a while and feel free to discuss & suggest additional additions or removals

[emilk]

Suggestions:

• clippy::needless_pass_by_value: helped us catch a lot of unnecessary : Vec<T> arguments and replace them with : &[T] in ark-modules, saving a lot of calls to .clone() (very common trap for rust beginners to fall into)

• clippy::unimplemented: I find unimplemented! to be very useful when stubbing out work-in-progress code, but I think we should avoid it on main (you can always temporarily allow it when it is motivated).

[emilk]

clippy::unnecessary_wraps was mentioned in #59 but without any motivation for exclusion. I like it in theory, and it did catch a few problems in ark-modules when I tried it out there a few weeks back

[repi]

• clippy::needless_pass_by_value: helped us catch a lot of unnecessary : Vec<T> arguments and replace them with : &[T] in ark-modules, saving a lot of calls to .clone() (very common trap for rust beginners to fall into)

cool, seen it used in a few crates but haven't tested that much myself with it. but sounds like a great idea!

• clippy::unimplemented: I find unimplemented! to be very useful when stubbing out work-in-progress code, but I think we should avoid it on main (you can always temporarily allow it when it is motivated).

ah yes that one could be interesting! we'll have to check a bit how we use it in different systems, but a new systems that is WIP can indeed opt into it.

clippy::unnecessary_wraps was mentioned in #59 but without any motivation for exclusion. I like it in theory, and it did catch a few problems in ark-modules when I tried it out there a few weeks back

that one is is definitely nice in concept, used it manually a few times. But it has multiple blocking issues: https://github.com/rust-lang/rust-clippy/issues?q=is%3Aissue+is%3Aopen+unnecessary_wraps, will link the key ones in #59

[aron-granberg]

(positing here instead because that seems to be the better place)

Personally I really don't like clippy::suboptimal_flops, in particular because it forces you to write a.mul_add(2.0, 4.0) instead of a * 2.0 + 4.0 which imo is a lot more readable than the former.

[repi]

Personally I really don't like clippy::suboptimal_flops, in particular because it forces you to write a.mul_add(2.0, 4.0) instead of a * 2.0 + 4.0 which imo is a lot more readable than the former.

that lint is indeed a bit messy with some of those suggestions, there are smaller and simpler fixes it does that are great, but a lot of math expressions do get remangled quite a bit for performance which can be a bit too much. we do have it disabled on some crates (including shaders).

We could potentially remove it, though many of the other smaller suggestions are good.

[aron-granberg]

Yeah, I really wish that it was broken up into one or two smaller lints since most of the other ones are a pure win both from a performance and a readability perspective.

[repi]

Yeah, I really wish that it was broken up into one or two smaller lints since most of the other ones are a pure win both from a performance and a readability perspective.

Agreed that would be nice, you could try filing a clippy GitHub issue suggestion on it? Looks pretty common to split up / refine lints that way

[aron-granberg]

@repi rust-lang/rust-clippy#6867

[repi]

Narrowed down a concrete working set of additional lints and tested both in Ark and in Rust GPU (https://github.com/EmbarkStudios/ark/pull/3302) and seems to work well and should get feedback from that tomorrow.

A bunch of lints didn't make it, but that is fine, there will be later future versions and good not to do giant lists of lints as increases the risk and integration challenge with them.

Anyone strongly object to any of the new lints? (not for some instances or specific crate, as that can be #[allow(xx)] - but object to the idea of one of the lints (or its implementation)?

[repi]

@MarijnS95 feel free to check this out as well!

[MarijnS95]

@repi Thanks! Looks good on our side except for large_types_passed_by_value and match_same_arms, we have some things to address 😅

[MarijnS95]

large_types_passed_by_value, while uncovering some moves that are better passed by value also triggers on constructors where we would like to "move" larger structs straight into another struct rather than borrowing first, then dereference (Copy) or clone them in the struct constructor. Not sure what we're going to do here, perhaps remove the large struct from our structs in the first place :)

[luna-duclos]

LGTM, all very nice suggestions, I'd love to see needless_pass_by_value added soon too, as its a trap we very often fall into as a team less experienced with rust!

@iffyio would you have time to see if we trip any of these additions in the src repo ?

[repi]

LGTM, all very nice suggestions, I'd love to see needless_pass_by_value added soon too, as its a trap we very often fall into as a team less experienced with rust!

Glad to hear it, and yes that lint is really good also, it does have some a bit tricky workarounds in some cases I've found in Ark, but have mostly gotten it working with it so think we can include it in the next version.

[repi]

large_types_passed_by_value, while uncovering some moves that are better passed by value also triggers on constructors where we would like to "move" larger structs straight into another struct rather than borrowing first, then dereference (Copy) or clone them in the struct constructor. Not sure what we're going to do here, perhaps remove the large struct from our structs in the first place :)

Ah interesting, and good feedback! I could see that happening for some cases, if it is just for a pretty specific case with a very big value and you don't want to refactor it, then likely fine to just allow the lint in that location. Clippy lints aren't perfect for everything and is intended to opt out here and there, and this lint does feel like a good default but can't easily work absolutely everywhere

[MarijnS95]

if it is just for a pretty specific case with a very big value and you don't want to refactor it, then likely fine to just allow the lint in that location

Joke's on us, we found out dead_code was allowed on large parts of the codebase some time ago and quickly scambled to correct most violations while prefixing a bunch of parameters with _ to refactor later. This large struct is one of the unused ones and has been removed altogether 😂, now we can safely run with this lint. Thanks again to this nice list to help us uncover hidden gems!