Add compiler-internal lints

[oli-obk]

There are various "patterns" we don't want in the compiler out of one reason or another. I'm using this issue to collect them and create lints for detecting those patterns. The lints will only be available while building the compiler via a -Z flag. The flag will be enabled by the bootstrap script, so we don't have to worry about accidentally running them for users.

• forbid uses of HashSet or HashMap (suggest FxHash*)
• suggest using TyCtxtAt over TyCtxt + Span as arguments
• calling clone on Copy types (Lint against calling .clone() on an otherwise copyable value. #27266)
• do not use features_untracked when a tcx is in scope
• do not use TyKind::Foo, use ty::Foo instead
• do not use TyKind as a type outside the sty module, use Ty instead
• don't use TyS outside rustc::ty::sty
• don't use Vec::new() use vec![]
• don't use == for span contexts, use eq_ctxt instead (Implement an internal lint encouraging use of Span::eq_ctxt #116787)
• prefer param_env_reveal_all_normalized over parram_env(did).with_reveal_all_normalized() (Avoid some unnecessary query invocations. #121387 (comment))
• require 'tcx to be the last lifetime in generic args of type decls, functions and impls (see Lifetime cleanups #130294) E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
• forbid storing a TyCtxt and a Session in the same struct or use both in function args. Only use tcx E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.

[leonardo-m]

Why are HashSet and HashMap forbidden as dog food for the compiler? And why aren't they "forbidden" for user code? This seems a hint.

[Ixrec]

If I remember correctly, it's because the standard HashSet/Map make a significant effort to protect against DoS attacks, i.e. they try to make it impossible for an attacker to induce huge performance cliffs with special sequences of malicious inputs (for example: https://accidentallyquadratic.tumblr.com/post/153545455987/rust-hash-iteration-reinsertion), but that concern doesn't apply inside the compiler so it makes more sense to use a faster implementation that does not offer any such protection.

[eddyb]

@Ixrec Also, it's useful to have deterministic compilation, without sources of randomness.

[oli-obk]

cc rust-lang/rust-clippy#3724

Implementing this lint in clippy will make rustc miss out on it. On the other hand, we could setup clippy to run on rustc similar to tidy

[flip1995]

The first and the last two items can be checked.

About the Clone on Copy lint: Would it make sense to uplift this lint completely to rustc? What's the state of the "no new lints in rustc" rule?

[oli-obk]

That rule still applies, can we move it to rustc as an internal lint but have clippy "reexport" it as its own lint?