support elision in impl headers #49251
Conversation
|
Oh, still running tests locally. |
1873a9f to
b149319
Compare
|
Looks good! |
|
☔ The latest upstream changes (presumably #49264) made this pull request unmergeable. Please resolve the merge conflicts. |
It'd be pretty buggy if `None` were supplied anyway; we'd skip over in-band lifetimes completely!
`'_` is illegal in structs; this currently gets a duplicate error
Deprecated forms of elision are not supported.
b149319 to
94468da
Compare
| lt_defs: &[LifetimeDef], | ||
| f: F | ||
| ) -> T where F: FnOnce(&mut LoweringContext) -> T | ||
| lt_defs: impl Iterator<Item = &'l LifetimeDef>, |
There was a problem hiding this comment.
Huh-- this is interesting. Seems like this would probably trigger #44752, but it's an error to omit the lifetime. We should probably be able to make argument-position impl Trait elided lifetimes "just work", but it's backcompat to fix, so I'm not super concerned about it.
There was a problem hiding this comment.
We should probably be able to make argument-position impl Trait elided lifetimes "just work", but it's backcompat to fix, so I'm not super concerned about it.
Yeah, that was curious, but I came to the same conclusion. I think clearly they should work as a fresh lifetime (but I feel the same about '_ in where clauses).
There was a problem hiding this comment.
Should probably file an issue about it.
|
@bors r+ |
|
📌 Commit 94468da has been approved by |
|
@bors p=1 |
…r=cramertj
support elision in impl headers
You can now do things like:
```
impl MyTrait<'_> for &u32 { ... }
```
Each `'_` or elided lifetime is a fresh parameter. `'_` and elision are still not permitted in associated type values. (Plausibly we could support that if there is a single input lifetime.) The original lifetime elision RFC was a bit unclear on this point: [as documented here, I think this is the correct interpretation, both because it fits existing impls and it's most analogous to the behavior in fns](#15872 (comment)).
We do not support elision with deprecated forms:
```
impl MyTrait for std::cell::Ref<u32> { } // ERROR
```
Builds on the in-band lifetime stuff.
r? @cramertj
Fixes #15872
|
☀️ Test successful - status-appveyor, status-travis |
…atsakis Extract impl_header_lifetime_elision out of in_band_lifetimes This way we can experiment with `impl Debug for &MyType` separately from `impl Debug for &'a MyType`. I can't say I know what the code in here is doing, so please let me know if there's a better way 🙂 I marked this as enabled in 2018 so that edition code continues to work without another flag. Actual feature PR #49251; Tracking Issue #15872; In-band lifetimes tracking issue #44524. cc @aturon, per discussion on discord earlier cc @cramertj & @nikomatsakis, who actually wrote these features
You can now do things like:
Each
'_or elided lifetime is a fresh parameter.'_and elision are still not permitted in associated type values. (Plausibly we could support that if there is a single input lifetime.) The original lifetime elision RFC was a bit unclear on this point: as documented here, I think this is the correct interpretation, both because it fits existing impls and it's most analogous to the behavior in fns.We do not support elision with deprecated forms:
Builds on the in-band lifetime stuff.
r? @cramertj
Fixes #15872