Initial implementation of `#![feature(move_ref_pattern)]`
Following up on #45600, under the gate `#![feature(move_ref_pattern)]`, `(ref x, mut y)` is allowed subject to restrictions necessary for soundness. The match checking implementation and tests for `#![feature(bindings_after_at)]` is also adjusted as necessary.
Closes#45600.
Tracking issue: #68354.
r? @matthewjasper
codegen: misc cleanups around debuginfo scopes and locations.
See each commit message. Most of these seem to be leftovers from the transition to MIR codegen.
r? @nagisa cc @bjorn3
Mark several functions and methods in core::cmp as #[must_use]
These functions and methods aren't mutating functions and ignoring the result of them is likely a bug in the user's code.
Don't use the word "unwrap" to describe "unwrap" methods
It's tautological, and "unwrap" is essentially Rust-specific jargon.
I was teaching a newbie some Rust, and doing the usual hand-waving about error handling using unwrap. They asked what 'unwrap' means. I said look it up in the docs. The docs read (paraphrased) "unwrap unwraps". I was embarrassed.
This changes all the Option/Result functions with unwrapping behavior to use a variation on a single description:
> "Returns the contained `Some/Ok` value [or ...]."
It also renames the closure of `Result::unwrap_or_else` to `default` for consistency with `Option`, and perhaps makes a few other small tweaks.
Previous: https://github.com/rust-lang/rust/pull/68849
perf: Reduce Vec allocations in normalization by passing &mut Vec
Complicates the code a bit but allocation/freeing were a few percent of the overall runtime in trait heavy code.
Fix and test implementation of BTreeMap's first/last_entry, pop_first/last
Properly implement and test `first_entry` & `last_entry` to fix problem report #68829
Move `rustc_hir::def_id` to `rustc_span::def_id`
This will allow `HygieneData` to refer to `DefId` and `DefIndex`, which
will enable proper serialization of Span hygiene information.
This also reduces the number of things imported from `rustc_hir`, which
might make it easier to remove dependencies on it.
rustc_codegen_ssa: don't treat inlined variables as debuginfo arguments.
Fixes#67586 by limiting `ArgumentVariable` special-casing to `VarDebugInfo` entries that are in `OUTERMOST_SOURCE_SCOPE`, i.e. the function's own argument scope.
That excludes `VarDebugInfo` from inlined callees, which can also point to the caller's argument locals.
This is a snippet from the optimized MIR (including inlining) of the testcase:
```rust
fn foo(_1: usize) -> usize {
debug bar => _1; // in scope 0 at ./example.rs:2:12: 2:15
let mut _0: usize; // return place in scope 0 at ./example.rs:2:27: 2:32
scope 1 {
debug x => _1; // in scope 1 at /rustc/9ed29b6ff6aa2e048b09c27af8f62ee3040bdb37/src/libcore/convert/mod.rs:106:26: 106:27
}
```
`scope 1` is from inlining the `identity` call, and `debug x => _1;` comes from the body of `core::convert::identity`, so they are now ignored for the purposes of determining the `ArgumentVariable` debuginfo associated to `_1`.
rustc_target: treat enum variants like union members, in call ABIs.
Fixes#68190, by handling non-C-like `enum`s as-if they were an `union` of `struct`s, in call ABIs.
Tests were provided by @sw17ch, from theirs and @bitwalker's original examples.
cc @nagisa @rkruppe
One calls into C functions passing non-c-like enumerations by
value. The other calls into C expecting non-C-like enumerations as
returns.
These test cases are based on the tests provided by @bitwalker on
issue #68190. The original tests were provided at:
2688d5c672
Remove some unsound specializations
This removes the unsound and exploitable specializations in the standard library
* The `PartialEq` and `Hash` implementations for `RangeInclusive` are changed to avoid specialization.
* The `PartialOrd` specialization for slices now specializes on a limited set of concrete types.
* Added some tests for the soundness problems.
replace the leak check with universes, take 2
This PR is an attempt to revive the "universe-based region check", which is an important step towards lazy normalization. Unlike before, we also modify the definition of `'empty` so that it is indexed by a universe. This sidesteps some of the surprising effects we saw before -- at the core, we no longer think that `exists<'a> { forall<'b> { 'b: 'a } }` is solveable. The new region lattice looks like this:
```
static ----------+-----...------+ (greatest)
| | |
early-bound and | |
free regions | |
| | |
scope regions | |
| | |
empty(root) placeholder(U1) |
| / |
| / placeholder(Un)
empty(U1) -- /
| /
... /
| /
empty(Un) -------- (smallest)
```
This PR has three effects:
* It changes a fair number of error messages, I think for the better.
* It fixes a number of bugs. The old algorithm was too conservative and caused us to reject legal subtypings.
* It also causes two regressions (things that used to compile, but now do not).
* `coherence-subtyping.rs` gets an additional error. This is expected.
* `issue-57639.rs` regresses as before, for the reasons covered in #57639.
Both of the regressions stem from the same underlying property: without the leak check, the instantaneous "subtype" check is not able to tell whether higher-ranked subtyping will succeed or not. In both cases, we might be able to fix the problem by doing a 'leak-check like change' at some later point (e.g., as part of coherence).
This is a draft PR because:
* I didn't finish ripping out the leak-check completely.
* We might want to consider a crater run before landing this.
* We might want some kind of design meeting to cover the overall strategy.
* I just remembered I never finished 100% integrating this into the canonicalization code.
* I should also review what happens in NLL region checking -- it probably still has a notion of bottom (empty set).
r? @matthewjasper
