Split librustc::{traits,infer} to a separate crate rustc_infer
This is still very much work in progress.
Three functions are between dimensions (at the end of `rustc::traits`), waiting for some dependency breaking scheme.
Please tell me if the approach seems sound, and how you would like to split this PR up.
The formatting is deliberately off, to ease rebasing.
cc #65031
rustc_session: allow overriding lint level of individual lints from a group
Fixes#58211 and fixesrust-lang/rust-clippy#4778 and fixesrust-lang/rust-clippy#4091
Instead of hard-coding the lint level preferences (from lowest to highest precedence: `lint::Allow -> lint::Warn -> lint::Deny -> lint::Forbid`), the position of the argument in the command line gets taken into account.
Examples:
1. Passing `-D unused -A unused-variables` denies everything in the lint group `unused` **except** `unused-variables` which is explicitly allowed.
1. Passing `-A unused-variables -D unused` denies everything in the lint group `unused` **including** `unused-variables` since the allow is specified before the deny (and therefore overridden by the deny).
This matches the behavior that is already being used when specifying `allow`/`deny` in the source code.
Record proc macro harness order for use during metadata deserialization
Fixes#68690
When we generate the proc macro harness, we now explicitly recorder the
order in which we generate entries. We then use this ordering data to
deserialize the correct proc-macro-data from the crate metadata.
Without `Compiletest.path` set running `x.py test src/test/rustdoc-js` would run the `rustdoc-js` test suite with everything filtered out.
As this was the only place setting `Compiletest.path` to `None` this removes the `Option` wrapper as well.
Fixes#68690
When we generate the proc macro harness, we now explicitly recorder the
order in which we generate entries. We then use this ordering data to
deserialize the correct proc-macro-data from the crate metadata.
