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?

[flip1995]

This could be possible by making the LintPass public in rustc and re-registering the LintPass in Clippy. I'm curious how this will work with tool_lints 🤔

[eddyb]

Hmm, instead of "don't do X outside of the Y module" - can we simply allow it, not on the whole Y module, but on the smallest piece of Y that needs to do X? E.g.:

#[allow(usage_of_ty_tykind)]
pub use self::TyKind::*;

[Centril]

New internal lint idea:

• ban identifiers did (also vid, ...) when they refer to DefID and similar.

cc @oli-obk #61350 (comment)

[flip1995]

Internal lint idea:

• Check that error / lint / help / ... messages start lower case

This is a unwritten / hard to find rule of the rust compiler, which new contributors, especially in Clippy often get wrong (and is sometimes overlooked by the reviewers). Since rustc has a huge amount of functions that can produce error / lint / help / ... messages, this lint could be a bit tedious to implement.

[oli-obk]

Moderately stupid idea: just panic in the Diagnostic type if a string argument starts with a capitalized character.

[Centril]

cc #63186

[jyn514]

ban pub use foo::bar;, #65233

This issue was closed, I think it should be removed from the list.

calling clone on Copy types (#27266)

That issue was closed because there's a clippy lint for it - maybe bootstrap should just pass -W clippy::clone_on_copy?

[oli-obk]

That issue was closed because there's a clippy lint for it - maybe bootstrap should just pass -W clippy::clone_on_copy?

bootstrap doesn't run with clippy yet. I guess we could replace ./x.py check with a clippy run with the beta clippy?

[jyn514]

That issue was closed because there's a clippy lint for it - maybe bootstrap should just pass -W clippy::clone_on_copy?

bootstrap doesn't run with clippy yet. I guess we could replace ./x.py check with a clippy run with the beta clippy?

It works imperfectly since #77351. It shouldn't be terribly hard to make it use beta clippy, I just haven't gotten around to it (right now it uses the default clippy of your host toolchain).