Downgrade let_unit_value to pedantic
Given that the false positive in #1502 is marked E-hard and I don't have much hope of it getting fixed, I think it would be wise to disable this lint by default. I have had to suppress this lint in every substantial codebase (\>100k line) I have worked in. Any time this lint is being triggered, it's always the false positive case.
The motivation for this lint is documented as:
> A unit value cannot usefully be used anywhere. So binding one is kind of pointless.
with this example:
> ```rust
> let x = {
> 1;
> };
> ```
Sure, but the author would find this out via an unused_variable warning or from `x` not being the type that they need further down. If there ends up being a type error on `x`, clippy's advice isn't going to help get the code compiling because it can only run if the code already compiles.
changelog: Remove let_unit_value from default set of enabled lints
Fix update_lints
This fixes a bug in update_lints, where `internal` lints were not registered properly. This also cleans up some code. For example: The code generation functions no longer filter the lints the are given. This is now the task of the caller. This way, it is more obvious in the `replace_in_file` calls which lints will be included in which part of a file.
This also turns the lint modules private. There is no need for them to be public, since shared code should be in the utils module anyway.
And last but not least, this fixes the `register_lints` code generation, so also internal lints get registered.
changelog: none
Use assoc int and float consts instead of module level ones
changelog: Recommend primitive type associated constants instead of module level constants
In Rust 1.43 integer and float primitive types will have a number of new associated constants. For example `MAX`, `MIN` and a number of constants related to the machine representation of floats. https://github.com/rust-lang/rust/pull/68952
These new constants are preferred over the module level constants in `{core,std}::{f*, u*, i*}`. I have in the last few days made sure that the documentation in the main rust repository uses the new constants in every place I could find (https://github.com/rust-lang/rust/pull/69860, https://github.com/rust-lang/rust/pull/70782). So the next step is naturally to make the linter recommend the new constants as well.
This PR only changes two lints. There are more. But I did not want the PR to be too big. And since I have not contributed to clippy before it felt saner to start with a small PR so I see if there are any quirks. More will come later.
rustup: update for the new Ty::walk interface.
The first commit fixes a portability bug in `setup-toolchain.sh`, while the second rewrites the handling of "trait impl methods" in `use_self` - even if `Ty::walk` could've still been used, it was IMO a misuse.
This could also serve as a PSA: *please* use `hir_ty_to_ty` instead of trying to compare `hir::Ty`s between themselves or against semantic `Ty`s. Its "quasi-deprecation" is 3 years old and doesn't really mean anything, just that it's currently uncached and that we should eventually querify it (either for a single HIR node, or for all of the nodes in an entire definition).
---
changelog: none
Result<T, E> has an `ok()` method that adapts a Result<T,E> into an Option<T>.
It's possible to get around this adapter by writing Result<T,E>.map_or(None, Some).
This lint is implemented as a new variant of the existing
[`option_map_none` lint](https://github.com/rust-lang/rust-clippy/pull/2128)
Improve docs for option_option
Hint about using tri-state enums to replace legitimate uses of `Option<Option<_>>`
changelog: The docs for `option_option` now suggest using a tri-state enum
