New Lint: use of built-in (or prelude) type as identifier

[scottmcm]

This compiles today, but doesn't do what many expect:

    struct Foo { x: u32 }
    let y = Foo { x: 4 };
    let Foo { x: u32 } = y;

https://play.rust-lang.org/?gist=2b9bb2b1e25b5a9d85c7adecf301fd22&version=stable

It would be nice if that gave a lint like "variable/module/function/macro u32 has the same name as a built-in type". Could possibly also apply to things like let Vec = 4; too, but I suspect that's less likely because of casing conventions.

cc https://internals.rust-lang.org/t/random-musings-types-in-patterns/7316/9?u=scottmcm
cc https://github.com/rust-lang/rust/blob/9da2112238c565a7e36ada0a1f9c899961910131/src/test/run-pass/weird-exprs.rs#L87-L104

[MajorBreakfast]

I think that there should be a warning whenever a binding is created that shadows a type in general. This has got to be accidental in 99.9% of all cases!

let u32 = 42i32; // No warning

Try in Playground

This might even make sense to put into the compiler directly.

[vks]

This might even make sense to put into the compiler directly.

The standard library contains modules that share a name with primitives. Other libraries might want to do the same.

[CAD97]

I think it's worth bumping this: it seems like any case of using a builtin or prelude name as something other than said name is suspicious at best. If libraries are doing so on purpose, then it makes sense to mark that with an #[allow] attribute.

An interesting case is the importing of deliberately-shadowing identifiers, such as core::f32. The common usage of these modules is now deprecated (use the associated constants on the type instead, but things like core::f32::consts` are still around and expected to be used.

I think the nicest thing to do would be to not fire such a lint for any item that was annotated with #[allow(clippy::shadowing_builtin_names)]/#[allow(clippy::shadowing_prelude_names)], but I don't know, to be fully honest.