better

Also split out emitters into their own module.

nodes in statement position.

Extended #[cfg] folder to allow removal of statements, and
of expressions in optional positions like expression lists and trailing
block expressions.

Extended lint checker to recognize lint levels on expressions and
locals.

to do "in-situ" visits.

visit nested items). This is what all clients wanted anyhow.

+ Add helper macro for walking lists (including Options)

[breaking-change] for lint authors

You must now implement LateLintPass or EarlyLintPass as well as LintPass and use either register_late_lint_pass or register_early_lint_pass, rather than register_lint_pass.

There is a minor [breaking-change] for lint authors - some functions which were previously defined on `lint::Context` have moved to a trait - `LintContext`, you may need to import that trait to avoid name resolution errors.

This could be a [breaking-change] if your lint or syntax extension (is that even possible?) uses HIR attributes or literals.

Currently, `early_error` and `early_warn` in `librustc::session` always
use `ColorConfig::Auto`. Modify them to follow the color configuration
set by the `--color` option.

As colored output is also printed during the early stage, parsing the
`--color` option should be done as early as possible. However, there are
still some cases when the output needs to be colored before knowing the
exact color settings. In these cases, it will be defaulted to
`ColorConfig::Auto`, which is the same as before.

Fixes #27879.

This commit is an implementation of [RFC 1193][rfc] which adds the ability to
the compiler to cap the lint level for the entire compilation session. This flag
will ensure that no lints will go above this level, and Cargo will primarily use
this flag passing `--cap-lints allow` to all upstream dependencies.

[rfc]: https://github.com/rust-lang/rfcs/pull/1193

Closes #27259

and deprecate/remove unsigned_negation lint.

This is useful to avoid causing breaking changes in case #![deny(unknown_lints)]
is used and lint is removed.

It now says '#[feature] may not be used on the stable release channel'.

I had to convert this error from a lint to a normal compiler error.

I left the lint previously-used for this in place since removing it is
a breaking change. It will just go unused until the end of time.

Fixes #24125

* The lint visitor's visit_ty method did not recurse, and had a
  reference to the now closed #10894
* The newly enabled recursion has only affected the `deprectated` lint
  which now detects uses of deprecated items in trait impls and
  function return types
* Renamed some references to `CowString` and `CowVec` to `Cow<str>` and
  `Cow<[T]>`, respectively, which appear outside of the crate which
  defines them
* Replaced a few instances of `InvariantType<T>` with
  `PhantomData<Cell<T>>`
* Disabled the `deprecated` lint in several places that
  reference/implement traits on deprecated items which will get cleaned
  up in the future
* Disabled the `exceeding_bitshifts` lint for
  compile-fail/huge-array-simple test so it doesn't shadow the expected
  error on 32bit systems
* Unfortunately, this means that if a library declares
  `#![deny(deprecated)]` and marks anything as deprecated, it will have
  to disable the lint for any uses of said item, e.g. any impl the now
  deprecated item

For any library that denies deprecated items but has deprecated items
of its own, this is a [breaking-change]

Traits can have associated types and not just methods. This
clarification reflects the the type of the input the method accepts.

[breaking-change]

This pulls out the implementations of most built-in lints into a
separate crate, to reduce edit-compile-test iteration times with
librustc_lint and increase parallelism. This should enable lints to be
refactored, added and deleted much more easily as it slashes the
edit-compile cycle to get a minimal working compiler to test with (`make
rustc-stage1`) from

    librustc -> librustc_typeck -> ... -> librustc_driver ->
        libcore -> ... -> libstd

to

    librustc_lint -> librustc_driver -> libcore -> ... libstd

which is significantly faster, mainly due to avoiding the librustc build
itself.

The intention would be to move as much as possible of the infrastructure
into the crate too, but the plumbing is deeply intertwined with librustc
itself at the moment. Also, there are lints for which diagnostics are
registered directly in the compiler code, not in their own crate
traversal, and their definitions have to remain in librustc.

This is a [breaking-change] for direct users of the compiler APIs:
callers of `rustc::session::build_session` or
`rustc::session::build_session_` need to manually call
`rustc_lint::register_builtins` on their return value.

This should make #22206 easier.