Add some more tests

expand: Stop marking derive helper attributes as known

Pass them through name resolution instead

resolve: Introduce a new scope for derive helpers

resolve: `Scope::DeriveHelpers` -> `Scope::DeriveHelpersCompat`

These helpers are resolved before their respective derives through a kind of look ahead into future expansions.
Some of these will migrate to proper resolution, others will be deprecated.

```
#[trait_helper] // Deprecate
#[derive(Trait)]
#[trait_helper] // Migrate to proper resolution
```

Auto merge of #66333 - mark-i-m:fix-rustc-guide-1, r=ehuss

Fix rustc guide again

r? @ehuss

Sorry, links change fast in this world...

Use "field is never read" instead of "field is never used"

avoid linking errors

miri panic_unwind: fix hack for SEH platforms

add missing 'static lifetime in docs

The example refers to a static lifetime parameter that can be elided.
This parameter is not included, meaning lifetime elision is not shown.

Auto merge of #66255 - ehuss:update-cc, r=alexcrichton

Update cc, git2, num_cpus.

This updates the `cc` crate, bringing in better parallel building support. Also updates `git2` which enables the parallel feature. (Note: I don't expect it will have a significant impact on build time, but seems good to update anyways.)

The main thorn is that `cc` gained knowledge about RISC-V architectures (https://github.com/alexcrichton/cc-rs/pull/428, https://github.com/alexcrichton/cc-rs/pull/429, https://github.com/alexcrichton/cc-rs/pull/430), but the builders on CI do not have the riscv C compiler installed. This means that bootstraps' cc detection was finding a C compiler that isn't installed, and fails.

The solution here is to override the cc detection to `false`. The C compiler isn't actually used on riscv platforms. AFAIK, the only location would be compiler_builtins, and it currently forces C support off (https://github.com/rust-lang/compiler-builtins/blob/a533ae9c5aa325db209659679535fe1f186eae81/build.rs#L49-L55).

Other possible solutions:
- Add the override in cc_detect for riscv (or any "no-C" platform like wasm32 and nvptx)
- Install and use the appropriate c compiler. I tried this the `g++-riscv64-linux-gnu` package, but it failed missing some header file.

Closes #66232

Auto merge of #66453 - Centril:rollup-w1ohzxs, r=Centril

Rollup of 5 pull requests

Successful merges:

 - #66350 (protect creation of destructors by a mutex)
 - #66407 (Add more tests for fixed ICEs)
 - #66415 (Add --force-run-in-process unstable option to libtest)
 - #66427 (Move the JSON error emitter to librustc_errors)
 - #66441 (libpanic_unwind for Miri: make sure we have the SEH lang items when needed)

Failed merges:

r? @ghost

move DIAGNOSTICS usage to rustc_driver

Auto merge of #66326 - Nadrieril:refactor-intrange, r=varkor

Refactor integer range handling in the usefulness algorithm

Integer range handling had accumulated a lot of debt. This cleans up a lot of it.

In particular this:
- removes unnecessary conversions between `Const` and `u128`, and between `Constructor` and `IntRange`
- clearly distinguishes between on the one hand ranges of integers that may or may not be matched exhaustively, and on the other hand ranges of non-integers that are never matched exhaustively and are compared using Const-based shenanigans
- cleans up some overly complicated code paths
- generally tries to be more idiomatic.

As a nice side-effect, I measured a 10% perf increase on `unicode_normalization`.

There's one thing that I feel remains to clean up: the [overlapping range check](https://github.com/rust-lang/rust/pull/64007), which is currently quite ad-hoc. But that is intricate enough that I'm leaving it out of this PR.

There's also one little thing I'm not sure I understand: can `try_eval_bits` fail for an integer constant value in that code ? What would that mean, and how do I construct a test case for this possibility ?

Respond to review feedback

[ConstProp] Avoid OOM crashes by not evaluating large Places

Fixes #66397

Fix spurious CI filures due to OOM

Fixes #66342

Update src/llvm-project to include rust-lang/llvm-project#27.

Change makefile back to python27.

Remove newtype for qualifs in `rustc_metadata`

We have a proper type for these now, so the wrapper is no longer
necessary.

Fix nits from review

Use `mir::QualifSet` to store qualifs

Use a bespoke type for the result of `mir_const_qualif`

A `Downcast` is now reached when const-checking a `for` loop

I believe this occurs because the old checker stopped processing basic
blocks after a `SwitchInt`.

Remove -Z flag for suppressing validation mismatch ICE

Add explanation of test for validation mismatch

Silence miri unleashed warnings in test

Remove unnecessary `fmt::Debug` bound

Remove remaining validator mismatch code

Move `delay_span_bug` into `emit_error` for if/loop

Remove `qualify_consts` completely

Use new const-checker for `mir_const_qualif`

Now `mir_const_qualif` must be called for `static`s and `const fn`s as
well as `const`s since it is responsible for const-checking. We return
the qualifs in the return place for everything, even though they will
only be used for `const`s.

Enable standalone const-checking with `Validator`

Unlike the original pass, we check *every* non-cleanup basic block
instead of stopping at `SwitchInt`. We use the `is_cfg_cyclic` function
to check for loops unlike the original checker which could not differentiate
between true cycles and basic blocks with more than two predecessors.

The last three functions are all copied verbatim from `qualify_consts`.

Allow `Validator` to get qualifs for the return place

Remove `requires_sync`

Remove `QUALIF_ERROR_BIT` checking

Rollup merge of #66441 - RalfJung:seh, r=oli-obk

libpanic_unwind for Miri: make sure we have the SEH lang items when needed

r? @oli-obk  @alexcrichton This is required to fix the Miri toolstate. Turns out rustc complains when doing codegen for MSVC and these lang items do not exist. For now `cfg(miri)` needs to still be able to codegen (we [plan to change that](https://github.com/rust-lang/miri/pull/1048#issuecomment-554108470) but that's a larger project requiring improvements to xargo and maybe also cargo; that should not block fixing the toolstate). Yes, this is a hack, but it is inside `cfg(miri)` so I hope this is okay.

Cc @Aaron1011

Rollup merge of #66427 - Mark-Simulacrum:errors-json, r=Centril

Move the JSON error emitter to librustc_errors

This is done both as a cleanup (it makes little sense for this emitter to be in libsyntax), but also as part of broader work to decouple Session from librustc itself.

Along the way, this also moves SourceMap to syntax_pos, which is also nice for the above reasons, as well as allowing dropping the SourceMapper trait from code. This had the unfortunate side-effect of moving `FatalError` to rustc_data_structures (it's needed in syntax_pos, due to SourceMap, but putting it there feels somehow worse).

Rollup merge of #66415 - tmandry:force-test-in-process, r=alexcrichton

Add --force-run-in-process unstable option to libtest

When running tests with `-Zpanic_abort_tests`, it's sometimes desirable to fall back to the old behavior of only running tests in-process. This comes in handy if the system process launcher is unavailable, or the test code somehow expects all tests to be run in the same process.

For example, in Fuchsia we have unit tests that actually test the process launcher itself, in which case we can't use the process launcher to run the tests :).

r? @alexcrichton
cc @cramertj,@petrhosek

Rollup merge of #66407 - JohnTitor:add-ice-tests, r=Centril

Add more tests for fixed ICEs

Closes #36122 (fixed in 1.20.0)
Closes #58094 (fixed in #66054)
Also, fix mistaken test case, from #30904 to #30906 (cc @eddyb)

r? @Centril

Rollup merge of #66350 - hermitcore:hermit, r=rkruppe

protect creation of destructors by a mutex

- add on HermitCore an additional lock to protect static data

Apply suggestions from code review

Add regression test

Apply suggestions from code review

Factor out IntRange::is_subrange

Apply suggestions from code review

Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>

Add test for failing `try_eval_bits`

Remove fishy condition

That condition was leftover from a refactor, and was probably not
intended. In fact it can't trigger: it would require a ConstantValue of
an integral type for which `try_eval_bits` fails. But since we only
apply `subtract_ctors` to the output of `all_ctors`, this won't happen.

Malformed range patterns can't happen thanks to E0030

Remove unnecessary data from ConstantValue/ConstantRange

Store Const directly in ConstantRange

Make should_treat_range_exhaustively a method

Inline now-trivial IntRange::from_ctor

Factor out getting the boundaries of an `IntRange`

Eagerly convert ranges to IntRange

That way no `ConstantRange` or `ConstantValue` ever needs to be
converted to `IntRange`.

Add `IntRange::to_pat` and use it instead of custom `display()`

Fix nll test

formatting

Introduce IntRange constructor

`Constructor::display` was only needed for displaying `IntRange`

I'm planning to stop using `ConstantRange`/`ConstantValue` for integral
types, so going through `Constructor` will soon not be relevant.

Avoid converting through Constructor when subtracting ranges

Special-case subtracting from a range if that range is not an IntRange

Prefer IntRange::into_ctor to range_to_ctor

Move range exhaustiveness check to IntRange::intersection

Only IntRange should need to worry about range exhaustiveness really.

Special-case range inclusion when the range is integral but non-exhaustive

Cleanup `constructor_covered_by_range`

IntRange::from_pat is redundant with pat_constructors

`pat_constructor` does not need `pcx` anymore

Factor out range construction in `all_constructors`

Clarify conditions for exhaustive integer range matching

Note link between apply/specialize/arity functions

more comment

Apply suggestion from Centril

Co-Authored-By: Mazdak Farrokhzad <twingoow@gmail.com>

Fix test case and issue number

Add test for issue-58094

Add test for issue-36122

Improve error message for tests with panic=abort

Add --force-run-in-process unstable libtest option

Move JSON emitter to rustc_errors

Remove SourceMapper trait

SourceMap is now in the root of all rustc-specific crates, syntax_pos,
so there's no need for the trait object to decouple the dependencies
between librustc_errors and libsyntax as was needed previously.

Auto merge of #66449 - tmandry:rollup-3p1t0sb, r=tmandry

Rollup of 4 pull requests

Successful merges:

 - #66197 (Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering)
 - #66429 (Add a regression test for #62524)
 - #66435 (Correct `const_in_array_repeat_expressions` feature name)
 - #66443 (Port erased cleanup)

Failed merges:

r? @ghost

Rollup merge of #66443 - GuillaumeGomez:port-erased-cleanup, r=Mark-Simulacrum

Port erased cleanup

Just realised that the changes I made in #65965 were removed after the move of all error codes so here it is. I made them into separate commits to make the history look better this time.

r? @Mark-Simulacrum

Rollup merge of #66435 - JohnTitor:fix-spelling, r=Centril

Correct `const_in_array_repeat_expressions` feature name

Fixes #66433

r? @estebank

Rollup merge of #66429 - guanqun:add-unit-test, r=Centril

Add a regression test for #62524

Closes #62524

Rollup merge of #66197 - Centril:transparent-ast, r=varkor

Push `ast::{ItemKind, ImplItemKind}::OpaqueTy` hack down into lowering

We currently have a hack in the form of `ast::{ItemKind, ImplItemKind}::OpaqueTy` which is constructed literally when you write `type Alias = impl Trait;` but not e.g. `type Alias = Vec<impl Trait>;`. Per https://github.com/rust-lang/rfcs/pull/2515, this needs to change to allow `impl Trait` in nested positions.  This PR achieves this change for the syntactic aspect but not the semantic one, which will require changes in lowering and def collection. In the interim, `TyKind::opaque_top_hack` is introduced to avoid knock-on changes in lowering, collection, and resolve. These hacks can then be removed and fixed one by one until the desired semantics are supported.

r? @varkor

Move SourceMap to syntax_pos

This does not update the use sites or delete the now unnecessary
SourceMapper trait, to allow git to interpret the file move as a rename
rather than a new file.

Move FatalError to syntax_pos

This is a bit unfortunate, but code needs to be able to fatally error
early on (in particular, syntax_pos after we move SourceMap there). It's
also a tiny bit of code, which means it's ultimately not that bad.

Clean up E0025, E0034, E0044, E0046 and E0053

Clean up E0054

Clean up E0050

Clean up E0049

Clean up E0045

Clean up E0040

Clean up E0033

Clean up E0029

Clean up E0027

Clean up E0026

Add link to error code explanation RFC

find_deprecation: deprecation attr may be ill-formed meta.

Clean up E0023

libpanic_unwind for Miri: make sure we have the SEH lang items when needed