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
Work around a resolve bug in const prop
r? @wesleywiser @anp
This isn't exposed right now, but further changes to rustc may start causing bugs without this.
Refactor expression parsing thoroughly
Based on https://github.com/rust-lang/rust/pull/66994 together with which this has refactored basically the entirety of `expr.rs`.
r? @estebank
Teach `compiletest` to ignore platform triples
The UI tests are written assuming `--remap-path-prefix` is *not used* (`remap-debuginfo` in `config.toml`). The consequence is that the error messages may include paths and snippets into the standard library. When `remap-debuginfo` is enabled, these messages change in format and structure because `rustc` will not show paths and snippets into the standard library.
This normally isn't a problem for the "main" platforms (linux/macos/windows), because the CI infrastructure is set up so that the tests run without `remap-debuginfo`, but the `dist` artifacts are built separately with `remap-debuginfo` enabled. However, some of the lower-tier platforms perform both tests and distribution in a single step with `remap-debuginfo` enabled. This also affects developers and distributors who use `remap-debuginfo`.
To sidestep this problem, we add a way to ignore tests in specific platform triples, and update the overly broad `ignore-x86` rule in affected tests.
Address #46948, #54546, #53081.
doc comments: Less attribute mimicking
Make sure doc comments are not converted into intermediate meta-items, or not mixed with `doc(inline)` or something like that.
Follow-up to https://github.com/rust-lang/rust/pull/65750.
During MIR interpretation it may happen that a place containing
uninitialized bytes is copied. This would read the current
representation of these bytes and write it to the destination even
though they must, by definition, not matter to the execution.
This elides that representation change when no bytes are defined in such
a copy, saving some cpu cycles. In such a case, the memory of the target
allocation is not touched at all which also means that sometimes no
physical page backing the memory allocation of the representation needs
to be provided by the OS at all, reducing memory pressure on the system.
prune ill-conceived BTreeMap iter_mut assertion and test its mutability
Proposal to deal with #67438 (and I'm more sure now that this is the right thing to do).
Passes testing with miri.
