introduce type-op for user-type ascription in NLL
Handle user-type ascription in a type operator, which gives us a lot more flexibility around the order in which we resolve things.
r? @pnkfelix
Fixes#55219Fixes#55241
Add regression tests for #55219 and #55241
Also another test where a duplicate-like error appears to have been
suppressed; I'm not 100% sure why this output changes, though I could
imagine that some duplicate suppression is enabled by this PR.
enforce user annotations in closure signatures
Not *quite* ready yet but I'm opening anyway. Still have to finish running tests locally.
Fixes#54692Fixes#54124
r? @matthewjasper
This fixes `issue-28848.rs` -- it also handles another case that the
AST region checker gets wrong (`wf-self-type.rs`). I don't actually
think that this is the *right way* to be enforcing this constraint --
I think we should probably do it more generally, perhaps by editing
`predicates_of` for the impl itself. The chalk-style implied bounds
setup ought to fix this.
#45829 when a renamed import conflict with a previous import
Fix the suggestion when a renamed import conflict.
It check if the snipped contains `" as "`, and if so uses everything before for the suggestion.
[NLL] Use new region infer errors when explaining borrows
Use the new free region infer errors for explaining borrows
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure to a captured variable. (E0521)
Closes#51026 - `regions-nested-fns-2.rs` isn't changed to that diagnostic, since that would not be the correct error here.
Closes#51169
cc #53882 - The error is (IMO) better now, but it could be better when we trace lifetimes in these error messages.
r? @nikomatsakis cc @pnkfelix
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value
referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure
to a captured variable.
Rollup of 5 pull requests
Successful merges:
- #55156 (Fixed: Multiple errors on single typo in match pattern)
- #55189 (update books for the next release)
- #55193 (make asm diagnostic instruction optional)
- #55203 (Write an initial version of the `program_clauses` callback)
- #55213 (ignore target folders)
Failed merges:
r? @ghost
The issue of passing around SIMD types as values between functions has
seen [quite a lot] of [discussion], and although we thought [we fixed
it][quite a lot] it [wasn't]! This PR is a change to rustc to, again,
try to fix this issue.
The fundamental problem here remains the same, if a SIMD vector argument
is passed by-value in LLVM's function type, then if the caller and
callee disagree on target features a miscompile happens. We solve this
by never passing SIMD vectors by-value, but LLVM will still thwart us
with its argument promotion pass to promote by-ref SIMD arguments to
by-val SIMD arguments.
This commit is an attempt to thwart LLVM thwarting us. We, just before
codegen, will take yet another look at the LLVM module and demote any
by-value SIMD arguments we see. This is a very manual attempt by us to
ensure the codegen for a module keeps working, and it unfortunately is
likely producing suboptimal code, even in release mode. The saving grace
for this, in theory, is that if SIMD types are passed by-value across
a boundary in release mode it's pretty unlikely to be performance
sensitive (as it's already doing a load/store, and otherwise
perf-sensitive bits should be inlined).
The implementation here is basically a big wad of C++. It was largely
copied from LLVM's own argument promotion pass, only doing the reverse.
In local testing this...
Closes#50154Closes#52636Closes#54583Closes#55059
[quite a lot]: https://github.com/rust-lang/rust/pull/47743
[discussion]: https://github.com/rust-lang/rust/issues/44367
[wasn't]: https://github.com/rust-lang/rust/issues/50154
Fixed: Multiple errors on single typo in match pattern
Here we have fixed the case where we were throwing two diagnostic messages `E0026` and `E0027` for same case.
Example
```
error[E0026]: variant `A::A` does not have a field named `fob`
--> src/test/ui/issue-52717.rs:20:12
|
20 | A::A { fob } => { println!("{}", fob); }
| ^^^ variant `A::A` does not have this field
error[E0027]: pattern does not mention field `foo`
--> src/test/ui/issue-52717.rs:20:5
|
20 | A::A { fob } => { println!("{}", fob); }
| ^^^^^^^^^^^^ missing field `foo`
error: aborting due to 2 previous errors
```
Here above we can see that both `E0026` and `E0027` are depicting
same thing.
So, to fix this issue, we are simply checking if for last element of `inexistent_fields` is there any value lies in `unmentioned_fields` using levenshtein algorithm, if it does then for that case we are simply deleting element from `unmentioned_fields`. More or less, now instead of showing separate message in `E0027` we are giving extra hint on `E0026`
r? @estebank
Allow explicit matches on ! without warning
It's now possible to explicitly match on `!` without an unreachable code warning. This seems desirable as promoting explicitness.
Fixes https://github.com/rust-lang/rust/issues/55116.
handle underscore bounds in unexpected places
Per the discussion on #54902, I made it a hard error to use lifetime bounds in various places where they used to be permitted:
- `where Foo: Bar<'_>` for example
I also moved error reporting to HIR lowering and added `Error` variants to let us suppress downstream errors that result.
I (imo) improved the error message wording to be clearer, as well.
In the process, I fixed the ICE in #52098.
Fixes#54902Fixes#52098
