-
Notifications
You must be signed in to change notification settings - Fork 306
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
Include type arguments in Type Hierarchy #4217
Comments
Is there anyway I can help ? I've worked quite a lot with the analyzer API |
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. |
@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 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 |
To the best of my knowledge, we don't have any support for serializing and deserializing instances of The easiest way I can think of off-hand would be to keep the 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 |
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. |
ultra reactive ! I've been sick all day, I am feeling better and I'll take a look tomorrow |
@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). |
Fixes Dart-Code/Dart-Code#4217. Change-Id: I8b8dec4ad25a9eb4a4f80dd036e8a9b61bb012d2 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/264981 Reviewed-by: Brian Wilkerson <brianwilkerson@google.com> Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
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. |
When browsing the hierarchy from A, we see a node for
B
but it doesn't include<String>
(or<T>
).The text was updated successfully, but these errors were encountered: