Rollup of 7 pull requests
Successful merges:
- #68718 (Move `rustc_hir::def_id` to `rustc_span::def_id`)
- #68834 (Fix and test implementation of BTreeMap's first/last_entry, pop_first/last)
- #68857 (perf: Reduce Vec allocations in normalization by passing &mut Vec)
- #68918 (Don't use the word "unwrap" to describe "unwrap" methods)
- #68946 (Mark several functions and methods in core::cmp as #[must_use])
- #68958 (Clean up E0277 and E0282 explanations)
- #68960 (codegen: misc cleanups around debuginfo scopes and locations.)
Failed merges:
r? @ghost
When suggesting associated fn with type parameters, include in the structured suggestion
Address #50734.
```
error[E0046]: not all trait items implemented, missing: `foo`, `bar`, `baz`
--> file.rs:14:1
|
14 | impl TraitA<()> for S {
| ^^^^^^^^^^^^^^^^^^^^^ missing `foo`, `bar`, `baz` in implementation
|
= help: implement the missing item: `fn foo<T>(_: T) -> Self where T: TraitB, TraitB::Item = A { unimplemented!() }`
= help: implement the missing item: `fn bar<T>(_: T) -> Self { unimplemented!() }`
= help: implement the missing item: `fn baz<T>(_: T) -> Self where T: TraitB, <T as TraitB>::Item: std::marker::Copy { unimplemented!() }`
```
It doesn't work well for associated types with `ty::Predicate::Projection`s as we need to resugar `T: Trait, Trait::Assoc = K` → `T: Trait<Assoc = K>`.
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
Selectively disable sanitizer instrumentation
Add `no_sanitize` attribute that allows to opt out from sanitizer
instrumentation in an annotated function.
BtreeMap range_search spruced up
#39457 created a lower level entry point for `range_search` to operate on, but it's really not hard to move it up a level of abstraction, making it somewhat shorter and reusing existing unsafe code (`new_edge` is unsafe although it is currently not tagged as such).
Benchmark added. Comparison says there's no real difference:
```
>cargo benchcmp old3.txt new3.txt --threshold 5
name old3.txt ns/iter new3.txt ns/iter diff ns/iter diff % speedup
btree::map::find_seq_100 19 21 2 10.53% x 0.90
btree::map::range_excluded_unbounded 3,117 2,838 -279 -8.95% x 1.10
btree::map::range_included_unbounded 1,768 1,871 103 5.83% x 0.94
btree::set::intersection_10k_neg_vs_10k_pos 35 37 2 5.71% x 0.95
btree::set::intersection_staggered_100_vs_10k 2,488 2,314 -174 -6.99% x 1.08
btree::set::is_subset_10k_vs_100 3 2 -1 -33.33% x 1.50
```
r? @Mark-Simulacrum
It's tautological, and Rust-specific Jargon.
This changes various Option/Result methods to consistently describe unwrapping
behavior using the words "return", "contain", "consume".
It also renames the closure argument of `Return::unwrap_or_else` to `default` to
be consistent with `Option`.
error code examples: replace some more ignore with compile_fail
Now that #68664 has been merged and `compile_fail` attempts a full build rather than `--emit=metadata`, these errors should be caught by `compile_fail` and do not need to be ignored.
Mark fn map_or() as eagerly evaluated.
In the docs for option.rs and result.rs, it is noted for all *_or()
functions that they are eagerly evaluated, except for the map_or()
function.
This commit adds this missing documentation to the two files.
Closes#68866
