fix future breakage for where-clause well-formedness #40
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hello there 👋,
I'm a member of the Rust types teams, and while helping out with the effort on the new trait solver,
modcholeskyshowed up in the results for an in-progress change. This change will land in a future version of rust and fix an issue in the compiler, which will cause this crate to stop compiling due to two small errors.The
index_of_largestfunctions use where-clauses that look into the associated type of a trait via a generic reference. The compiler checks the reference type passes certain checks ("well-formed") and in this rare situation did it in a way that missed possible issues in the function signature.A simplification of the issue looks like this
is accepted today but shouldn't, much like it is an error if the function is only looking for the
Databound, for example:The compiler change will reject the first case like it rejects the second case.
And this PR fixes these future errors so the crate continues to compile. This bound is already implied in
ndarraywhen using the variousArrayViewaliases so everything's fine of course, but when using these generically, one would either need aT: 'abound on the function, or not elide the lifetime to pick up that implied bound. Both could work here and the second way felt more common.