Add more automated checks for our code style

[jplatte]

We have had accidentally-private fields a bunch of times now, also mod.rs files have appeared a number of times after we initially moved away from them. I'd also like to enforce some other things, like how serde_json::Value should always be import-renamed to JsonValue. There might be existing tooling for some of this, but maybe it's also feasible to create new tooling for a few things.

[jplatte]

Trying to create an exhaustive list here:

• Check for mod.rs (easy)
• Check that all links to a particular spec point to the same version
  • Doesn't have to be syntax aware, could pretty much be a grep CI job
• Check that repetitions within quote! always use the same style. (low return on investment, low prio)
• Check non_exhaustive on public types (+ whitelist of types that don't need the attribute) – Enable exhaustive_structs lint in ruma-clippy #606
• Check import grouping – now part of rustfmt
• Check quote! is always used with curly braces (New lint: Check quote! macro is always used with curyl braces rust-lang/rust-clippy#7278)
• Check for private fields in public types (+ whitelist of types that are allowed to contain private fields)
• Check that dependencies in Cargo.toml are sorted – https://github.com/DevinR528/cargo-sort
• Check import renaming (New lint: enforce import renaming rust-lang/rust-clippy#7276)
• Check for (public?) usage of HashMap (New lint: disallowed_types based on config rust-lang/rust-clippy#7277)
  • Very similar: Check public usage of integer types (+ whitelist of types which are allowed to use the primitive ones?)

[iinuwa]

Would shell scripts to execute in CI suffice for (some of) these, or are you wanting to do something more robust?

(Reminds me of semgrep.)

[jplatte]

For stuff like finding mod.rs, shell code would be fine. For anything that is about the insides of a Rust source file I'd rather have tools can actually parse Rust. I think most of the ground work for this kind of analysis has been done with rerast and rust-analyzer's structural search & replace. We may also be able to leverage rustfmt 2.0 in some way.

[agraven]

Maybe JsonValue could be better signposted as the proper way to do things by having a pub use with it somewhere, maybe in ruma-common?

[jplatte]

And have other crates import it from there rather than serde_json? I kind of like having it obvious where it actually comes from. But it's certainly worth considering.

[jplatte]

I've checked off the check for private fields – this is now checked for all types that derive Outgoing, which isn't a perfect solution but makes it much less important to have a dedicated lint :)

[jplatte]

Import grouping is now part of rustfmt, but before we can actually use it there's two issues to be resolved:

• group_imports does not differentiate between a local import and an external crate rust-lang/rustfmt#4709
• group_imports = "StdExternalCrate" moved re-exports into use groups rust-lang/rustfmt#4723

[DevinR528]

Is this what your thinking of for the last checkbox https://github.com/DevinR528/cargo-sort-ck

[jplatte]

Probably :)

Can you send a PR adding that to our CI (the nightly job)?

[DevinR528]

So I'm working a bit on cargo sort-ck so that it is more robust and can handle workspaces. Formatting with the comments has proven to be a really complicated problem so I'm planning to make the basic failure functionality work really well. Shouldn't be too long, hopefully a day or two before I can start on the PR (famous last words 🙄 ).