"higher-ranked lifetime error" with no further explanation

1

Hey

I'm trying something eminently silly I'm sure, for which I will post a playground link if it gets to that, but at the moment I am getting a higher-ranked lifetime error from cargo test on certain lines in my test source - the weird thing is that there is no further explanation from the compiler - just higher-ranked lifetime error.

Can somebody explain in general what that actually means.

2

“Higher-ranked lifetimes” are the sort of lifetimes that occur in function types/traits when the function takes a reference, and can also appear in other situations. For example,

fn(&str) -> &str

is the type of a function pointer that can accept a string reference and produce another. But remember, every reference has a lifetime, so what are the lifetimes of these references? The most typically useful answer, and the one that follows the lifetime elision rules, is “the output lifetime equals the input lifetime”. But that's not a specific lifetime, it's a rule about relating them. So the type is actually:

for<'a> fn(&'a str) -> &'a str

which you should read as “for all possible lifetimes (the particular one of which we will call 'a), this is a function from &'a str to &'a str”.

The for<'a> syntax is most often seen in the context of higher-rank trait bounds (HRTB) because when the lifetimes are not in function types/traits, they need to be written explicitly rather than implicitly.

“higher-ranked lifetime error” is one of the rare cases where the compiler currently isn't good at giving you a helpful error message; reasoning about higher-ranked lifetimes is difficult and sometimes all it can say is “I failed to prove this property”. (The error should contain an additional note, not just the main error message.)

You'll need to share the code and the error to get any further advice on solving it.

2 Likes
3

Thanks for the response. It really isn't telling me anything more than the primary message. I'll work up a simpler recreation of the issue in playground and share here.

4

There are a couple of cases where there's no note attached because it's not yet clear what that should be (assuming this is even an error to begin with, rather than a compiler bug).

5

I'm fairly new to this - it's highly unlikely yo be a compiler bug! :smiley:

6

If you're doing something async you might be hitting this bug. If so, this comment contains a workaround.