Check for free regions in MIR validation
This turns https://github.com/rust-lang/rust/issues/108720 into a MIR validation failure that will reproduce without debug-assertions enabled.
```
error: internal compiler error: broken MIR in Item(WithOptConstParam { did: DefId(0:296 ~ futures_util[3805]::future::future::remote_handle::{impl#3}::poll), const_param_did: None }) (after pass ScalarReplacementOfAggregates) at bb0[0]:
Free regions in optimized runtime-post-cleanup MIR
--> /home/ben/.cargo/registry/src/github.com-1ecc6299db9ec823/futures-util-0.3.26/src/future/future/remote_handle.rs:96:13
|
96 | let this = self.project();
| ^^^^
```
Add regression tests for issue 70919
Desugaring DropAndReplace at MIR build (#107844) fixed#70919.
Add regressions tests, borrowed from #102078, to ensure we check for this in the future.
cc ``@Aaron1011``
const_eval: `implies_by` in `rustc_const_unstable`
Fixes#107605.
Extend support for `implies_by` (from `#[stable]` and `#[unstable]`) to `#[rustc_const_stable]` and `#[rustc_const_unstable]`.
cc ``@steffahn``
Allow using `bool` instead of `Option<()>` in diagnostics
~~Disallow the unit type for `#[help]`, `#[note]` etc, instead using `bool` to express optional annotations without a span which I believe is more intuitive.~~
~~Test output ordering has changed in a few places, where a field was of type `()` and the annotation has been moved to the struct itself. If any of these changes are an issue, this can be restricted to allowing specifically `()`, and not `Option<()>`~~
~~Actual changes here: https://github.com/rust-lang/rust/pull/108402/files#diff-815b1d8debfc564112bd51093791d7c3f2ee288a37a8f5c0e89c11d1f609b4c0~~
Allows using `bool` in derive diagnostics to indicate an optional subdiagnostic without a span, where previously `Option<()>` had to be used
`@rustbot` label +A-diagnostics
Rollup of 7 pull requests
Successful merges:
- #108244 (Add test for semicolon recovery ICE)
- #108746 (Don't project to RPITIT that has no default value)
- #108764 (Tweaks to -Zdrop-tracking-mir)
- #108770 (Improve documentation and argument naming of some TyCtxt methods)
- #108773 (x fmt: Only check modified files locally)
- #108775 (Use the correct bound vars in return type suggestion.)
- #108776 (Make `x test tidy` less noisy)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
An `assume` would definitely not be worth it, but since the flag is almost free we might as well tell LLVM this, especially on `_unchecked` calls where there's no obvious way for it to deduce it.
(Today neither safe nor unsafe indexing gets it: <https://rust.godbolt.org/z/G1jYT548s>)
Use `partial_cmp` to implement tuple `lt`/`le`/`ge`/`gt`
In today's implementation, `(A, B)::gt` contains calls to *both* `A::eq` *and* `A::gt`.
That's fine for primitives, but for things like `String`s it's kinda weird -- `(String, usize)::gt` has a call to both `bcmp` and `memcmp` (<https://rust.godbolt.org/z/7jbbPMesf>) because when `bcmp` says the `String`s aren't equal, it turns around and calls `memcmp` to find out which one's bigger.
This PR changes the implementation to instead implement `(A, …, C, Z)::gt` using `A::partial_cmp`, `…::partial_cmp`, `C::partial_cmp`, and `Z::gt`. (And analogously for `lt`, `le`, and `ge`.) That way expensive comparisons don't need to be repeated.
Technically this is an observable change on stable, so I've marked it `needs-fcp` + `T-libs-api` and will
r? rust-lang/libs-api
I'm hoping that this will be non-controversial, however, since it's very similar to the observable changes that were made to the derives (#81384#98655) -- like those, this only changes behaviour if a type overrode behaviour in a way inconsistent with the rules for the various traits involved.
(The first commit here is #108156, adding the codegen test, which I used to make sure this doesn't regress behaviour for primitives.)
Zulip conversation about this change: <https://rust-lang.zulipchat.com/#narrow/stream/219381-t-libs/topic/.60.3E.60.20on.20Tuples/near/328392927>.
x fmt: Only check modified files locally
Previously, `x fmt` would only format modified files, while `x fmt .` and `x fmt --check` would still look at all files. After this change, `x fmt --check` only looks at modified files locally.
I feel pretty confident in this change - other than https://github.com/rust-lang/rust/issues/106261, no one has reported bugs in `get_modified_rs_files` since it was added in https://github.com/rust-lang/rust/pull/105702.
Combined with the changes in https://github.com/rust-lang/rust/pull/108772, this brings the time for me to run `x t tidy` with a hot FS cache down from 5 to 2 seconds (and moves the majority of the time spent back to `tidy check`, which means it can be sped up more in the future).
Desugaring DropAndReplace at MIR build (#107844) fixed issue
70919. Add regressions tests, borrowed from #102078, to ensure we
check for this in the future.
Co-authored-by: Aaron Hill <aa1ronham@gmail.com>
We don't support old versions of LLVM; there's no reason to have an easy
way to force bootstrap to use them anyway. If someone really needs to
use an unsupported version, they can modify bootstrap to change the
version range.
Previously, `x fmt` would only format modified files, while `x fmt .`
and `x fmt --check` would still look at all files. After this change, `x
fmt --check` only looks at modified files locally.
I feel pretty confident in this change - other than
https://github.com/rust-lang/rust/issues/106261, no one has reported
bugs in `get_modified_rs_files` since it was added in
https://github.com/rust-lang/rust/pull/105702.
Rollup of 7 pull requests
Successful merges:
- #106440 (Ignore files in .gitignore in tidy)
- #108613 (Remove `llvm.skip-rebuild` option)
- #108616 (Sync codegen defaults with compiler defaults and add a ping message so they stay in sync)
- #108618 (Rename `src/etc/vscode_settings.json` to `rust_analyzer_settings.json`)
- #108626 (rustdoc-json: switch from HashMap to FxHashMap to fix non-determinism)
- #108744 (Don't ICE when encountering bound var in builtin copy/clone bounds)
- #108749 (Clean up rustdoc-js tester.js file)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
rustdoc-json: switch from HashMap to FxHashMap to fix non-determinism
Using `HashMap` in `rustdoc_json_types::Crate` were causing creating randomly ordered objects in the json doc files. Which might cause problems to people who are doing comparison on those files specially in CI pipelines. See https://github.com/rust-lang/rust/issues/103785#issuecomment-1307425590
This PR fixes that issue and extends the coverage of `tests/run-make/rustdoc-verify-output-files` testing ability.
