| Age | Commit message (Collapse) | Author | Lines |
|---|
|
[beta] Fail gracefully when encountering an HRTB in APIT.
Backport of https://github.com/rust-lang/rust/pull/97683
The diagnostic is a bit worse, but still better than an ICE.
r? `@ehuss`
|
|
|
|
|
|
don't do `Sized` and other return type checks on RPIT's real type
Fixes an ICE where we're doing `Sized` check against the RPIT's real type, instead of against the opaque type. This differs from what we're doing in MIR typeck, which causes ICE #97226.
This regressed in #96516 -- this adjusts that fix to be a bit more conservative. That PR was backported and thus the ICE is also present in stable. Not sure if it's worth to beta and/or stable backport, probably not the latter but I could believe the former.
r? `@oli-obk`
cc: another attempt to fix this ICE #97413. I believe this PR addresses the root cause.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Perform lifetime resolution on the AST for lowering
Lifetime resolution is currently implemented several times. Once during lowering in order to introduce in-band lifetimes, and once in the resolve_lifetimes query. However, due to the global nature of lifetime resolution and how it interferes with hygiene, it is better suited on the AST.
This PR implements a first draft of lifetime resolution on the AST. For now, we specifically target named lifetimes and everything we need to remove lifetime resolution from lowering. Some diagnostics have already been ported, and sometimes made more precise using available hygiene information. Follow-up PRs will address in particular the resolution of anonymous lifetimes on the AST.
We reuse the rib design of the current resolution framework. Specific `LifetimeRib` and `LifetimeRibKind` types are introduced. The most important variant is `LifetimeRibKind::Generics`, which happens each time we encounter something which may introduce generic lifetime parameters. It can be an item or a `for<...>` binder. The `LifetimeBinderKind` specifies how this rib behaves with respect to in-band lifetimes.
r? `@petrochenkov`
|
|
|
|
|
|
|
|
This attempts to bring better error messages to invalid method calls, by applying some heuristics to identify common mistakes.
The algorithm is inspired by Levenshtein distance and longest common sub-sequence. In essence, we treat the types of the function, and the types of the arguments you provided as two "words" and compute the edits to get from one to the other.
We then modify that algorithm to detect 4 cases:
- A function input is missing
- An extra argument was provided
- The type of an argument is straight up invalid
- Two arguments have been swapped
- A subset of the arguments have been shuffled
(We detect the last two as separate cases so that we can detect two swaps, instead of 4 parameters permuted.)
It helps to understand this argument by paying special attention to terminology: "inputs" refers to the inputs being *expected* by the function, and "arguments" refers to what has been provided at the call site.
The basic sketch of the algorithm is as follows:
- Construct a boolean grid, with a row for each argument, and a column for each input. The cell [i, j] is true if the i'th argument could satisfy the j'th input.
- If we find an argument that could satisfy no inputs, provided for an input that can't be satisfied by any other argument, we consider this an "invalid type".
- Extra arguments are those that can't satisfy any input, provided for an input that *could* be satisfied by another argument.
- Missing inputs are inputs that can't be satisfied by any argument, where the provided argument could satisfy another input
- Swapped / Permuted arguments are identified with a cycle detection algorithm.
As each issue is found, we remove the relevant inputs / arguments and check for more issues. If we find no issues, we match up any "valid" arguments, and start again.
Note that there's a lot of extra complexity:
- We try to stay efficient on the happy path, only computing the diagonal until we find a problem, and then filling in the rest of the matrix.
- Closure arguments are wrapped in a tuple and need to be unwrapped
- We need to resolve closure types after the rest, to allow the most specific type constraints
- We need to handle imported C functions that might be variadic in their inputs.
I tried to document a lot of this in comments in the code and keep the naming clear.
|
|
|
|
|
|
diagnostics: use correct span for const generics
Fixes #95616
|
|
Fix late-bound ICE in `dyn` return type suggestion
This fixes the root-cause of the attached issues -- the root problem is that we're using the return type from a signature with late-bound instead of early-bound regions. The change on line 1087 (`let Some(liberated_sig) = typeck_results.liberated_fn_sigs().get(fn_hir_id) else { return false; };`) makes sure we're grabbing the _right_ return type for this suggestion to check the `dyn` predicates with.
Fixes #91801
Fixes #91803
This fix also includes some drive-by changes, specifically:
1. Don't suggest boxing when we have `-> dyn Trait` and are already returning `Box<T>` where `T: Trait` (before we always boxed the value).
2. Suggestion applies even when the return type is a type alias (e.g. `type Foo = dyn Trait`). This does cause the suggestion to expand to the aliased type, but I think it's still beneficial.
3. Split up the multipart suggestion because there's a 6-line max in the printed output...
I am open to splitting out the above changes, if we just want to fix the ICE first.
cc: ```@terrarier2111``` and #92289
|
|
|
|
|
|
|
|
|
|
When encountering an unsatisfied trait bound, if there are no other
suggestions, mention all the types that *do* implement that trait:
```
error[E0277]: the trait bound `f32: Foo` is not satisfied
--> $DIR/impl_wf.rs:22:6
|
LL | impl Baz<f32> for f32 { }
| ^^^^^^^^ the trait `Foo` is not implemented for `f32`
|
= help: the following other types implement trait `Foo`:
Option<T>
i32
str
note: required by a bound in `Baz`
--> $DIR/impl_wf.rs:18:31
|
LL | trait Baz<U: ?Sized> where U: Foo { }
| ^^^ required by this bound in `Baz`
```
Mention implementers of traits in `ImplObligation`s.
Do not mention other `impl`s for closures, ranges and `?`.
|
|
Fixes #95616
|
|
|
|
|
|
Rollup of 5 pull requests
Successful merges:
- #95294 (Document Linux kernel handoff in std::io::copy and std::fs::copy)
- #95443 (Clarify how `src/tools/x` searches for python)
- #95452 (fix since field version for termination stabilization)
- #95460 (Spellchecking compiler code)
- #95461 (Spellchecking some comments)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
This PR attempts to clean up some minor spelling mistakes in comments
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
encountered.
This also registers obligations for the hidden type immediately.
|
|
|
|
|
|
of the owning function
|
|
|
|
|
|
This reverts commit 6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d, reversing
changes made to 78450d2d602b06d9b94349aaf8cece1a4acaf3a8.
|
|
r=Dylan-DPC
Add long error explanation for E0667
Part of #61137.
|
|
|
|
Skip pointing out ambiguous impls in alloc/std crates too in inference errors
This generalizes the logic in `annotate_source_of_ambiguity` to skip printing ambiguity errors traits in `alloc` and `std` as well, not just `core`.
While this does spot-fix the issue mentioned below, it would be nicer to generalize this logic, for example to detect when the trait predicate's `self_ty` has any numerical inference variables. Is it worthwhile to scrap this solution for one like that?
Fixes #93450
r? `@estebank`
feel free to reassign
|
|
|
|
Signed-off-by: codehorseman <cricis@yeah.net>
|
