[Merged by Bors] - small and mostly pointless refactoring

[danieleades]

What is says on the tin.

This has got more to do with making clippy slightly more quiet than it does with changing anything that might greatly impact readability or performance.

that said, deriving Default for a couple of structs is a nice easy win

[IceSentry]

Reducing clippy warning noise is always nice!

[mockersf]

a lot of those changes are in bevy_render, and will be lost with the current rewrite

[danieleades]

a lot of those changes are in bevy_render, and will be lost with the current rewrite

what's the action here? should we wait for that and rebase? or are you just warning me that all my hard work will be for naught?

[mockersf]

a lot of those changes are in bevy_render, and will be lost with the current rewrite

what's the action here? should we wait for that and rebase? or are you just warning me that all my hard work will be for naught?

Not sure, I think bevy_render will be replaced by bevy_render2 which you can find in branch pipelined-rendering. I don't know how much of what you did can be ported, I am not following the rewrite very closely

[danieleades]

squashed a few more lints. this repo is a pedant's dream

[TheRawMeatball]

I'd rather not have #![allow(type_complexity)] in the code, as that lint gives too many false positives with bevy, and so we just disable it when running cargo clippy. Aside from that, it all looks good.

[IceSentry]

I'd rather not have #![allow(type_complexity)] in the code, as that lint gives too many false positives with bevy, and so we just disable it when running cargo clippy. Aside from that, it all looks good.

That approach doesn't really work for anyone that runs clippy on save in their editor. Personally I don't mind having it in the code, but I get why people might not like that.

Could we introduce a clippy.toml instead? type_complexity is already allowed in CI so having a clippy.toml simply makes it more obvious than having it hidden in a CI pipeline.

[danieleades]

i don't mind. as soon as there's a consensus, i can update the PR

[TheRawMeatball]

Does such a thing as a Clippy.toml exist? From a quick search, these seem to not quite exist: rust-lang/cargo#5034, which is why I didn't suggest it.

[IceSentry]

I didn't look into it that much I just saw the beginning of the configuration section and assumed it would be enough https://github.com/rust-lang/rust-clippy#configuration

[IceSentry]

Adding this to .cargo/config.toml seems to work

[target.'cfg(feature = "cargo-clippy")']
rustflags = ["-Aclippy::type_complexity"]

But that would required adding config.toml to the repository and I'm not sure if we want that, but it could at least be added to the recommended configs.

[IceSentry]

So, from what I understand, clippy.toml is used for configuring lints and not allowing or denying specfic lints. Reading the doc for type_complexity https://rust-lang.github.io/rust-clippy/master/index.html#type_complexity it looks like it would be possible to simply increase the threshold that triggers the lint.

[danieleades]

I tend to use clippy.toml mainly for configuring the MSRV (does bevy have a MSRV??)

Adding a compiler flag to a cargo.toml is no different to adding the flags inline in the lib.rs file(s), and the latter is usually preferred. Although in a big workspace project like this one, you'd have to duplicate the flags in every crate

[danieleades]

There seems to be a few different solutions being thrown around in this thread, but what is the desired behaviour?

if it's to suppress the lint globally, i can just stick #![allow(clippy::type_complexity)] in the root.

[mockersf]

New renderer has been merged, causing a lot of conflicts. Do you want to update this PR?

[cart]

Looks good to me! Resolve that last conflict and revert the iter::Copied change and we're good to go!

[alice-i-cecile]

@cart I've done a fresh review pass and the changes you requested are complete :) This PR LGTM now.

[cart]

bors r+

[bors]

Pull request successfully merged into main.

Build succeeded:

• build-android
• build (nightly, ubuntu-latest)
• build (stable, macos-latest)
• build (stable, ubuntu-latest)
• build (stable, windows-latest)
• build-wasm (nightly, ubuntu-latest)
• build-wasm (stable, ubuntu-latest)
• check-benches
• check-doc
• check-markdown-links
• check-missing-examples-in-docs
• check-unused-dependencies
• ci
• markdownlint
• run-examples