| Age | Commit message (Collapse) | Author | Lines |
|---|
|
This reverts commit 253408b4090bc15b88bb5faecaf1e9765be80587.
|
|
|
|
|
|
|
|
Handle mismatched generic param kinds in trait impls betterly
- Check that generic params on a generic associated type are the same as in the trait definition
- Check that const generics are not used in place of type generics (and the other way round too)
r? `@lcnr`
|
|
Add and tweak const-generics tests
Closes #96654
Also correct the src/test/ui/const-generics/issues/issue-77357.rs test's issue number.
|
|
Followups for method call error change
Each commit is self-contained. Fixes most of the followup reviews from that PR.
r? `@estebank`
|
|
|
|
|
|
|
|
`run-pass` produces a JSON file when enabling save analysis.
|
|
|
|
|
|
|
|
|
|
|
|
Enforce static lifetimes in consts during late resolution
This PR moves the handling of implicitly and explicitly static lifetimes in constants from HIR to the AST.
|
|
|
|
Enforce Copy bounds for repeat elements while considering lifetimes
fixes https://github.com/rust-lang/rust/issues/95477
this is a breaking change in order to fix a soundness bug.
Before this PR we only checked whether the repeat element type had an `impl Copy`, but not whether that impl also had the appropriate lifetimes. E.g. if the impl was for `YourType<'static>` and not a general `'a`, then copying any type other than a `'static` one should have been rejected, but wasn't.
r? `@lcnr`
|
|
|
|
|
|
|
|
typeck and that they are Copy (with proper lifetime checks) in borrowck
|
|
|
|
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.
|
|
simplify const params diagnostic on stable
Resolves #95150
|
|
|
|
|
|
diagnostics: use correct span for const generics
Fixes #95616
|
|
|
|
|
|
|
|
|
|
|
|
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
|
|
|
|
This reverts commit 6499c5e7fc173a3f55b7a3bd1e6a50e9edef782d, reversing
changes made to 78450d2d602b06d9b94349aaf8cece1a4acaf3a8.
|
|
Try to evaluate in try unify and postpone resolution of constants that contain inference variables
We want code like that in [`ui/const-generics/generic_const_exprs/eval-try-unify.rs`](https://github.com/rust-lang/rust/compare/master...b-naber:eval-in-try-unify?expand=1#diff-8027038201cf07a6c96abf3cbf0b0f4fdd8a64ce6292435f01c8ed995b87fe9b) to compile. To do that we need to try to evaluate constants in `try_unify_abstract_consts`, this requires us to be more careful about what constants we try to resolve, specifically we cannot try to resolve constants that still contain inference variables.
r? `@lcnr`
|
|
|
|
|
|
|
|
r=davidtwco,oli-obk
Suggest adding `{ .. }` around a const function call with arguments
closes #91020
|
|
Better error for normalization errors from parent crates that use `#![feature(generic_const_exprs)]`
This PR implements a somewhat rudimentary heuristic to suggest using `#![feature(generic_const_exprs)]` in a child crate when a function from a foreign crate (that may have used `#![feature(generic_const_exprs)]`) fails to normalize during codegen.
cc: #79018
cc: #94287
|
|
|
|
|
|
|
|
|
|
regression for issue 90847
Adds a regression test for issue #90847
|
|
|
