-
Notifications
You must be signed in to change notification settings - Fork 12.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add 'static lifetime suggestion when GAT implied 'static requirement from HRTB #106747
Conversation
(rustbot has picked a reviewer for you, use r? to override) |
r? @estebank Need to change existing |
b2fe495
to
aaf1e98
Compare
@yanchen please rebase onto current master and move the test from |
ee8c86d
to
9a90b5a
Compare
None | ||
} | ||
}) | ||
.collect::<Vec<_>>(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seeing that you're only using it once afterwards, I don't think you need to collect this first, right? It can remain an iterator. Collecting has a marginal perf cost, but we can avoid it with confidence thanks to the type ownership system :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, agreed. The reason for keeping the code this way I thought was for more readability and ease of debugging.
9a90b5a
to
aadd58e
Compare
@bors r+ |
…tebank Add 'static lifetime suggestion when GAT implied 'static requirement from HRTB Fix for issue rust-lang#105507 The problem: When generic associated types (GATs) are from higher-ranked trait bounds (HRTB), they are implied 'static requirement (see [Implied 'static requirement from higher-ranked trait bounds](https://blog.rust-lang.org/2022/10/28/gats-stabilization.html#implied-static-requirement-from-higher-ranked-trait-bounds) for more details). If the user did not explicitly specify the `'static` lifetime when using the GAT, the current error message will only point out the type `does not live long enough` where the type is used, but not where the GAT is specified and how to fix the problem. The solution: Add notes at the span where the problematic GATs are specified and suggestions of how to fix the problem by adding `'static` lifetime at the right spans.
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#106244 (Improve Markdown styling in README) - rust-lang#106747 (Add 'static lifetime suggestion when GAT implied 'static requirement from HRTB) - rust-lang#106873 (dont randomly use `_` to print out const generic arguments) - rust-lang#106992 (Remove unused `#![feature(box_syntax)]` in `alloc`) - rust-lang#106995 (bump failing assembly & codegen tests from LLVM 14 to LLVM 15) - rust-lang#106996 (rustdoc: instead of `.setting-name { width: 100% }`, use default div CSS) - rust-lang#106997 (Add heapsort fallback in `select_nth_unstable`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Fix for issue #105507
The problem:
When generic associated types (GATs) are from higher-ranked trait bounds (HRTB), they are implied 'static requirement (see
Implied 'static requirement from higher-ranked trait bounds for more details). If the user did not explicitly specify the
'static
lifetime when using the GAT, the current error message will only point out the typedoes not live long enough
where the type is used, but not where the GAT is specified and how to fix the problem.The solution:
Add notes at the span where the problematic GATs are specified and suggestions of how to fix the problem by adding
'static
lifetime at the right spans.