Repository navigation
"late bound lifetime parameters" error should have a number and help text #80618
Description
Activity
- addedA-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-lifetimesArea: Lifetimes / regionsArea: Lifetimes / regionsC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.
on Jan 2, 2021 - addedA-error-codesArea: Explanation of an error code (--explain)Area: Explanation of an error code (--explain)
on Jan 2, 2021 @cole-miller are you interested in adding the
--explaintext? There's instructions at https://rustc-dev-guide.rust-lang.org/diagnostics/diagnostic-codes.html?highlight=code#diagnostic-codes, it should be fairly simple.Reacted by Cole Miller- addedE-easyCall for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue.
on Jan 2, 2021 @jyn514 sure thing! While I'm waiting for
./x.py test tidy... how much harder would it be to add thehelphint at the same time? I can always take a look at previous PRs to get a sense of what's required.Not too much harder I think :) See #76143 for an example of both.
* this error should have a number and accompanying `rustc --explain` text that discusses the early- vs. late-bound lifetime distinction and why specifying late-bound lifetime parameters explicitly is not allowedI agree this is needed no matter what.
* it should also have a `help` line that suggests adding `where 'a: 'a`I'm not sure this is the best solution though.
If there are no early bound lifetimes, just leaving off the lifetime specifier (as implied by the lint) also works:
let _ = f; // just leave off the lifetime specifier let _: for<'a> fn() = f; // With type ascription
In more complicated situations, the type ascription may be needed to specify the early bound lifetimes, but can sometimes still be used without forcing an early bound:
struct Foo<'a, 'b> { a: &'a(), b: &'b () } // There is an implicit late bound parameter due to &Foo; 'a and 'b are early bound fn mixed<'a: 'a, 'b: 'b>(_: &Foo<'a, 'b>) -> Foo<'a, 'b> { todo!() } // This happens to work but no lifetimes can be specified without lint or error let _ = mixed; // For example, this triggers the lint as a warning; specifying 1 or 3+ lifetimes triggers an error: // let _ = mixed::<'static, 'static>; // type ascription allows specifying the lifetimes without warning or error let _: for<'a> fn(&'a Foo<'static, 'static>) -> Foo<'static, 'static> = mixed;
However, it is sometimes necessary to force a lifetime to be early bound, as discussed in issue 42868 and friends. I don't know how tractable it is to detect when the force-early-bound workaround is or isn't required. On the third hand, if I understand the conversation in issue 42508, sometimes type ascription works where forcing an early bound does not.
without changing the meaning of the code at all
Not quite:
// These compiled with `mixed` defined as above. The first version fires the lint as a warning. let _ = mixed::<'static, 'static>; let _: for<'a> fn(&'a Foo<'static, 'static>) -> Foo<'static, 'static> = mixed; // Apply the suggested hint: fn mixed<'a: 'a, 'b: 'b, 'c: 'c>(_: &'c Foo<'a, 'b>) -> Foo<'a, 'b> { todo!() } // This now fails: expected 3 lifetime arguments let _ = mixed::<'static, 'static>; // This now fails: one type is more general than the other let _: for<'a> fn(&'a Foo<'static, 'static>) -> Foo<'static, 'static> = mixed;
Reacted by Cole MillerHi, @cole-miller could you claim this? Then it's easier to see which issues are not yet being worked on.
Reacted by Cole Miller@rustbot claim
Any work being done on this? I'd love to implement this as my first contribution.
I never got around to working on this, feel free to claim it!
@rustbot release-assignment
Alright cool! Can I have an example of what it should maybe look like?
@rustbot claim
@rustbot claim
- added a commit that references this issue
on Mar 19, 2023 I think this can be closed now?
Fixed by #107416.
Currently (tested on stable and nightly) if you try to compile this code
you get this error message:
There is no error number (like E0208) to pass to
rustc --explain. There's also no mention that you can fix this error without changing the meaning of the code at all by putting a vacuouswhereclause in the signature off, like this:See #42868 for background. (I'm not sure when that compatibility lint became a hard error; it seems to have happened without that tracking issue being updated. Maybe that has something to do with why the error has no number or
help.)I think:
rustc --explaintext that discusses the early- vs. late-bound lifetime distinction and why specifying late-bound lifetime parameters explicitly is not allowedhelpline that suggests addingwhere 'a: 'aHere is the URLO thread that prompted this issue:
https://users.rust-lang.org/t/what-is-the-meaning-of-a-a-in-rust-lifetime-parameters/53570
cc @petrochenkov