Update lints used in Twilight

[laralove143]

There are many lints in Rustc and Clippy that fall in line with our contribution guides that we are not making use of. Our way of setting lints could also be improved.

References for new lints

Rustc lints

A list of opt-in Rustc lints can be found here. It is best to only opt out of default lints on a statement-basis, rather than a workspace/crate basis.

Clippy Lints

These lint groups are opt-in and most lints in them are applicable for our use-case:

• Cargo
• Nursery
• Pedantic

Lints in the group of Restriction should not be enabled as a whole but there are some lints that we might find useful:

• absolute_paths
• as_underscore
• assertions_on_result_states
• clone_on_ref_ptr
• dbg_macro
• deref_by_slicing
• disallowed_script_idents
• empty_enum_variants_with_brackets
• empty_structs_with_brackets
• exhaustive_enums
• exhaustive_structs
• filetype_is_file
• float_cmp_const
• fn_to_numeric_cast_any
• format_push_string
• get_unwrap
• if_then_some_else_none
• impl_trait_in_params
• integer_division
• large_include_file
• let_underscore_must_use
• lossy_float_literal
• map_err_ignore
• mem_forget
• mixed_read_write_in_expression
• mod_module_files
• mutex_atomic
• pub_without_shorthand
• rc_mutex
• redundant_type_annotations
• ref_patterns
• renamed_function_params
• rest_pat_in_fully_bound_structs
• same_name_method
• semicolon_inside_block
• str_to_string
• string_add
• string_lit_chars_any
• string_to_string
• tests_outside_test_module
• try_err
• unneeded_field_pattern
• unseparated_literal_suffix

Some of these lints might be noisy, some of them might require a significant number of changes to apply, some may be unnecessary for our purposes, and some may actually not follow our current code-style. They are listed here as a reference for further discussion before a PR.

Some lints that should be here could be missing out of my mistake. The lints are ordered alphabetically (as they appear on the Clippy lints website) and comments to add missing lints are welcome.

New Way of Setting Lints

Currently, we are setting lints in each crate's respective lib.rs/main.rs file, which can cause discrepancies and leads to duplicate code across each crate. We were doing this because there was no other way to set lints. We can now set lints in Cargo.toml files (documentation, tracking issue). A few questions remain on whether this approach is viable though:

• Is there an MSRV implication of using this? Will this require us to increase our MSRV? Are the advantages of this usage worth the disadvantage of increasing our MSRV?
• Is this allowed in workspaces? Can we set lints for all crates in our workspace in the top-level Cargo.toml? If not, we would still have to duplicate the lints in all Cargo.toml files, which removes the advantage of this approach.

I was unable to find the answers to these questions but we can find out by simply trying.