Add wrap suggestions for record variants
This PR adds a suggestions to wrap an expression in a record struct/variant when encountering mismatched types, similarly to a suggestion to wrap expression in a tuple struct that was added before.
An example:
```rust
struct B {
f: u8,
}
enum E {
A(u32),
B { f: u8 },
}
fn main() {
let _: B = 1;
let _: E = 1;
}
```
```text
error[E0308]: mismatched types
--> ./t.rs:11:16
|
11 | let _: B = 1;
| - ^ expected struct `B`, found integer
| |
| expected due to this
|
help: try wrapping the expression in `B`
|
11 | let _: B = B { f: 1 };
| ++++++ +
error[E0308]: mismatched types
--> ./t.rs:12:16
|
12 | let _: E = 1;
| - ^ expected enum `E`, found integer
| |
| expected due to this
|
help: try wrapping the expression in a variant of `E`
|
12 | let _: E = E::A(1);
| +++++ +
12 | let _: E = E::B { f: 1 };
| +++++++++ +
```
r? `@compiler-errors`
Use `impl`'s generics when suggesting fix on bad `impl Copy`
See the UI test for a more complicated example, but we weren't correctly suggesting to add bounds given a manual `impl` whose generics didn't match the struct generics.
```rust
#[derive(Clone)]
struct Wrapper<T>(T);
impl<S> Copy for Wrapper<S> {}
```
Coincidentally this fix didn't cause any regressions for `derive(Copy)` impls, I think because those use the same spans in the impl generics as the struct generics, so the machinery still applies the same change.
use `check_region_obligations_and_report_errors` to avoid ICEs
If we don't call `process_registered_region_obligations` before `resolve_regions_and_report_errors` then we'll ICE if we have any region obligations, and `check_region_obligations_and_report_errors` just does both of these for us in a nice convenient function.
Fixes#53475
r? types
Rollup of 8 pull requests
Successful merges:
- #99227 (Fix thumbv4t-none-eabi frame pointer setting)
- #99518 (Let-else: break out scopes when a let-else pattern fails to match)
- #99671 (Suggest dereferencing index when trying to use a reference of usize as index)
- #99831 (Add Fuchsia platform support documentation)
- #99881 (fix ICE when computing codegen_fn_attrs on closure with non-fn parent)
- #99888 (Streamline lint checking)
- #99891 (Adjust an expr span to account for macros)
- #99904 (Cleanup html whitespace)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Adjust an expr span to account for macros
Fix this erroneous suggestion:
```
error[E0529]: expected an array or slice, found `Vec<{integer}>`
--> /home/gh-compiler-errors/test.rs:2:9
|
2 | let [..] = vec![1, 2, 3];
| ^^^^ pattern cannot match with input type `Vec<{integer}>`
|
help: consider slicing here
--> /home/gh-compiler-errors/rust2/library/alloc/src/macros.rs:50:36
|
50~ $crate::__rust_force_expr!(<[_]>::into_vec(
51+ #[rustc_box]
52+ $crate::boxed::Box::new([$($x),+])
53~ )[..])
```
fix ICE when computing codegen_fn_attrs on closure with non-fn parent
Other call sites check `has_codegen_attrs` first, so let's do that too.
Fixes#99876
add suggestion when there is a impl of external trait on pointer with wrong coherence rules
Closes https://github.com/rust-lang/rust/issues/99572
This will try to improve the node in the error message by suggesting a general solution because the solution, in this case, is application depended.
I'm not super happy regarding the code quality, but I'm happy to have feedback on it.
`@rustbot` r? `@compiler-errors`
Deeply deny fn and raw ptrs in const generics
I think this is right -- just because we wrap a fn ptr in a wrapper type does not mean we should allow it in a const parameter.
We now reject both of these in the same way:
```
#![feature(adt_const_params)]
#[derive(Eq, PartialEq)]
struct Wrapper();
fn foo<const W: Wrapper>() {}
fn foo2<const F: fn()>() {}
```
This does regress one test (`src/test/ui/consts/refs_check_const_eq-issue-88384.stderr`), but I'm not sure it should've passed in the first place.
cc: ``@b-naber`` who introduced that test^
fixes#99641
Check that RPITs constrained by a recursive call in a closure are compatible
Fixes#99073
Adapts a similar visitor pattern to `find_opaque_ty_constraints` (that we use to check TAITs), but with some changes:
0. Only walk the "OnlyBody" children, instead of all items in the RPIT's defining scope
1. Only walk through the body's children if we found a constraining usage
2. Don't actually do any inference, just do a comparison and error if they're mismatched
----
r? `@oli-obk` -- you know all this impl-trait stuff best... is this the right approach? I can explain the underlying issue better if you'd like, in case that might reveal a better solution. Not sure if it's possible to gather up the closure's defining usages of the RPIT while borrowck'ing the outer function, that might be a better place to put this check...
codegen: use new {re,de,}allocator annotations in llvm
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
r? `@nikic`
This obviates the patch that teaches LLVM internals about
_rust_{re,de}alloc functions by putting annotations directly in the IR
for the optimizer.
The sole test change is required to anchor FileCheck to the body of the
`box_uninitialized` method, so it doesn't see the `allocalign` on
`__rust_alloc` and get mad about the string `alloca` showing up. Since I
was there anyway, I added some checks on the attributes to prove the
right attributes got set.
While we're here, we also emit allocator attributes on
__rust_alloc_zeroed. This should allow LLVM to perform more
optimizations for zeroed blocks, and probably fixes#90032. [This
comment](https://github.com/rust-lang/rust/issues/24194#issuecomment-308791157)
mentions "weird UB-like behaviour with bitvec iterators in
rustc_data_structures" so we may need to back this change out if things
go wrong.
The new test cases require LLVM 15, so we copy them into LLVM
14-supporting versions, which we can delete when we drop LLVM 14.
Remove some explicit `self.infcx` for `FnCtxt`, which already derefs into `InferCtxt`
The use of `self.infcx.method_on_infcx` vs `self.method_on_infcx` when `self` is a `FnCtxt` is a bit inconsistent, so I'm moving some `self.infcx` usages I found to just use autoderef
