Skip to content

Conversation

@lqd
Copy link

@lqd lqd commented Nov 28, 2025

Hello there 👋,

I'm a member of the Rust types teams, and while helping out with the effort on the new trait solver, modcholesky showed 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_largest functions 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

pub struct View<A>(A);
pub trait Data {
    type Elem;
}
impl<'a, A> Data for View<&'a A> {
    type Elem = A;
}

pub fn repro<'a, T>()
where
    <View<&'a T> as Data>::Elem: Sized,
{
}

is accepted today but shouldn't, much like it is an error if the function is only looking for the Data bound, for example:

pub fn repro2<'a, T>()
where
    View<&'a T>: Data, // ERROR: `T` may not live long enough
{
}

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 ndarray when using the various ArrayView aliases so everything's fine of course, but when using these generically, one would either need a T: 'a bound 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant