Extract `rustc_ast_lowering` crate from `rustc`
Working towards https://github.com/rust-lang/rust/issues/65031.
This PR moves `src/librustc/hir/lowering{/, .rs}` to its own crate (`librustc_ast_lowering`) which is very self-contained (only `fn lower_crate` and `trait Resolver` are exposed).
r? @Mark-Simulacrum
Support `-Z ui-testing=yes/no`
`ui-testing` is now a boolean option (`-Z ui-testing=yes/no`) and can be specified multiple times with later values overriding earlier values (`-Z ui-testing=yes -Z ui-testing=no` == `-Z ui-testing=no`), so it can be set in a hierarchical way, e.g. UI testing infra may enable it by default with specific tests being able to opt-out.
This way we can remove the special opt-out support from `compiletest`.
Inspired by https://github.com/rust-lang/rust/pull/67709.
Allocate HIR on an arena 4/4
This is the fourth and last PR in the series started by #66931, #66936 and #66942.
The last commits should compile on their own.
The difference with the previous PR is given by https://github.com/cjgillot/rust/compare/hirene-ty...hirene
A few more cleanups may be necessary, please tell me.
r? @eddyb like the other
cc @Zoxc
Get rid of ErrorReportingCtx [5/N]
We can now use `MirBorrowckCtxt` instead :)
```
6 files changed, 122 insertions(+), 243 deletions(-)
```
This is a followup to (and thus blocked on) #67241.
r? @matthewjasper
cc @eddyb
I while try to do one more to get rid of the weird usage of `RegionInferenceCtx` in `borrow_check::diagnostics::{region_errors, region_naming}`. I think those uses can possibly also be refactored to use `MirBorrowckCtxt`...
Resolve long compile times when evaluating always valid constants
This extends the existing logic which skips validating every integer or
floating point number type to also skip validating empty structs because
they are also trivially valid.
Fixes#67539
r? @oli-obk
cc @RalfJung @spastorino
Rollup of 10 pull requests
Successful merges:
- #64273 (Stabilize attribute macros on inline modules)
- #67287 (typeck: note other end-point when checking range pats)
- #67564 (docs: Iterator adapters have unspecified results after a panic)
- #67622 (Some keyword documentation.)
- #67657 (Clean up const-hack PRs now that const if / match exist.)
- #67677 (resolve: Minor cleanup of duplicate macro reexports)
- #67687 (Do not ICE on lifetime error involving closures)
- #67698 (Move reachable_set and diagnostic_items to librustc_passes.)
- #67701 (tidy: Enforce formatting rather than just check it if `--bless` is specified)
- #67715 (Typo fix)
Failed merges:
r? @ghost
tidy: Enforce formatting rather than just check it if `--bless` is specified
Ensuring the "tidy"-ness currently requires running `rustfmt` twice:
```sh
./x.py fmt && ./x.py test tidy
```
, once to actually format code and the second time as a part of tidy to check that the code is formatted.
Running `rustfmt` is slow, so we don't want to run it twice.
With this PR tidy enforces the formatting rather than just checks it if `--bless` was passed to it:
```sh
./x.py test tidy --bless
```
r? @Mark-Simulacrum
resolve: Minor cleanup of duplicate macro reexports
Enabled by https://github.com/rust-lang/rust/pull/65785 which changed `duplicate_macro_exports` from a lint to a hard error.
Clean up const-hack PRs now that const if / match exist.
Closes#67627.
Cleans up these merged PRs tagged with `const-hack`:
- #63810
- #63786
- #61635
- #58044
reverting their contents to have the match or if expressions they originally contained.
r? @oli-obk
There's one more PR in those tagged with `const-hack` that originally wasn't merged (#65107). Reading the thread, it looks like it was originally closed because the `const-hack` for the checked arithmetic non-negligibly hurt performance, and because there was no way to manipulate the returned Option at compile time anyway (with neither const if nor const match). Would you like me to add these changes to the changes from this PR here too, now that we have the necessary features?
docs: Iterator adapters have unspecified results after a panic
Fixes#58170.
That issue also has rough consensus from 3 members of the library team for this being the behavior we would like to specify.
typeck: note other end-point when checking range pats
Fixes#57389, alternative to #67214 that should be less invasive to type checking logic.
r? @estebank
