-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Implement return position impl trait / opaque type support #4689
Conversation
Makes sense to me. More generally, after we do ItemTree work, it might makes sense to only store resolved things in |
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.
LGTM with new query accounted for in memory usage stats
TypeCtor::OpaqueType(opaque_ty_id) => { | ||
let bounds = match opaque_ty_id { | ||
crate::OpaqueTyId::ReturnTypeImplTrait(func, idx) => { | ||
let datas = |
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.
I wonder if we should switch to data/datum terminlology...
crates/ra_hir_ty/src/lower.rs
Outdated
let func = match ctx.resolver.generic_def() { | ||
Some(GenericDefId::FunctionId(f)) => f, | ||
_ => { | ||
// this shouldn't happen |
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.
This needs an assert
or an explanation why it isn't an assert
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.
Ok, added a panic instead. I'm sometimes not sure whether to assert or just ignore things like this in cases where there's an easy way to bail out without panicking.
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.
Good question...
I think for compilery things, it's better to panic, but for IDE things, it's probably better to try to soldier on.
I guess, at least debug_assert
always makes sense.
This is working, but I'm not that happy with how the lowering works. We might need an additional representation between `TypeRef` and `Ty` where names are resolved and `impl Trait` bounds are separated out, but things like inference variables don't exist and `impl Trait` is always represented the same way. Also note that this doesn't implement correct handling of RPIT *inside* the function (which involves turning the `impl Trait`s into variables and creating obligations for them). That intermediate representation might help there as well.
b2339e3
to
0d2328f
Compare
@matklad, I addressed your comments. |
bors r+ |
🎉 |
This is working, but I'm not that happy with how the lowering works. We might need an additional representation between
TypeRef
andTy
where names are resolved andimpl Trait
bounds are separated out, but things like inference variables don't exist andimpl Trait
is always represented the same way.Also note that this doesn't implement correct handling of RPIT inside the function (which involves turning the
impl Trait
s into variables and creating obligations for them). That intermediate representation might help there as well.