You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@bwilkerson with the ability to round-trip element locations, I had a look at this. Including the type arguments for the "next level" works fine because from an element when we get its supertypes/subtypes we have the type arguments (in an InterfaceType).
However, since we then only round-trip an element reference, those type args are lost in subsequent hops:
I guess it turns out that really I wanted to tround-trip the InterfaceType rather than the Element. Is there anything existing that might help with this, or do you have any suggestions for what might be a reasonable way? (I may still send what I've got so far in the meantime since I think this behaviour is probably still an improvement over not showing any type args at all).
To the best of my knowledge, we don't have any support for serializing and deserializing instances of InterfaceType (outside the summary file format, but I'm skeptical that we want to try to send binary data back and forth to the client).
The easiest way I can think of off-hand would be to keep the ElementLocation of the original element, then some indication of the "path" from that to the type we're trying to access. If the list of supertypes is stable then the path could just be the indexes into the lists of children.
I'm not sure whether it's worth the effort, so I'm happy to go either way with it.
But it does seem to me that it's better to be consistent, because I think it could be misleading not to be. As a result, I'd say we should either have all or none. That is, if we don't use an InterfaceType at every level of the hierarchy then we shouldn't use it at any level (and if we're not displaying actual types, then we should probably just drop the type arguments from the display).
If the list of supertypes is stable then the path could just be the indexes into the lists of children.
Interesting idea. I don't think we can guarantee they're stable (the type hierarchy nodes are long-lived on the client) but we could compare the new type we arrive at with the element location and ensure they still match up. If they don't, we could fall back to just showing the elements type parameters (as in the example above), but I think that will be an edge case (there's a Refresh button the user can use to re-sync the type hierarchy if they make changes that are likely to have affected its navigation, so having it sometimes go awry after changes is not unexpected).
And in the case where the type args are available:
Change hasn't landed yet, it's up for review at https://dart-review.googlesource.com/c/sdk/+/264981. This is an SDK change so once landed, it will show up in a future Dart/Flutter SDK release (and not a VS Code extension release).
Activity
dupuchba commentedon Oct 19, 2022
Is there anyway I can help ? I've worked quite a lot with the analyzer API
DanTup commentedon Oct 19, 2022
Right now this is blocked on me finishing https://dart-review.googlesource.com/c/sdk/+/264300 (which is blocked on another change I'm working on). I'm hoping to get them done fairly soon, though.
DanTup commentedon Oct 20, 2022
@bwilkerson with the ability to round-trip element locations, I had a look at this. Including the type arguments for the "next level" works fine because from an element when we get its supertypes/subtypes we have the type arguments (in an
InterfaceType).However, since we then only round-trip an element reference, those type args are lost in subsequent hops:
I guess it turns out that really I wanted to tround-trip the
InterfaceTyperather than theElement. Is there anything existing that might help with this, or do you have any suggestions for what might be a reasonable way? (I may still send what I've got so far in the meantime since I think this behaviour is probably still an improvement over not showing any type args at all).bwilkerson commentedon Oct 20, 2022
To the best of my knowledge, we don't have any support for serializing and deserializing instances of
InterfaceType(outside the summary file format, but I'm skeptical that we want to try to send binary data back and forth to the client).The easiest way I can think of off-hand would be to keep the
ElementLocationof the original element, then some indication of the "path" from that to the type we're trying to access. If the list of supertypes is stable then the path could just be the indexes into the lists of children.I'm not sure whether it's worth the effort, so I'm happy to go either way with it.
But it does seem to me that it's better to be consistent, because I think it could be misleading not to be. As a result, I'd say we should either have all or none. That is, if we don't use an
InterfaceTypeat every level of the hierarchy then we shouldn't use it at any level (and if we're not displaying actual types, then we should probably just drop the type arguments from the display).DanTup commentedon Oct 20, 2022
Interesting idea. I don't think we can guarantee they're stable (the type hierarchy nodes are long-lived on the client) but we could compare the new type we arrive at with the element location and ensure they still match up. If they don't, we could fall back to just showing the elements type parameters (as in the example above), but I think that will be an edge case (there's a Refresh button the user can use to re-sync the type hierarchy if they make changes that are likely to have affected its navigation, so having it sometimes go awry after changes is not unexpected).
I'll give it a go and see how it works.
dupuchba commentedon Oct 20, 2022
ultra reactive ! I've been sick all day, I am feeling better and I'll take a look tomorrow
DanTup commentedon Oct 25, 2022
@dupuchba hope you're feeling better!
I was able to make this work properly using Brian's suggestion above. Types are now shown (and correctly flow across supertypes):
Your example from #4226 looks like this:
And in the case where the type args are available:
Change hasn't landed yet, it's up for review at https://dart-review.googlesource.com/c/sdk/+/264981. This is an SDK change so once landed, it will show up in a future Dart/Flutter SDK release (and not a VS Code extension release).
[analysis_server] Include type arguments in Type Hierarchy
DanTup commentedon Oct 31, 2022
This changed landed in dart-lang/sdk@27ba8fc. It's part of the SDK so will show up in a future Dart/Flutter SDK release.
[analysis_server] Always show type parameters in LSP type hierarchy, …