Variable hover should show the origin of the given type

[FMorschel]

I was instructed by DanTup to post this issue here as well. The original is fully described below:

From Dart-Code/Dart-Code#5206

Describe the problem
Variable hover should show the origin of the given type.

This is pretty important in cases where there are types with the same name and they don't have any relation to one another like the sample, but I also see significance if they extend one another and they are inverted in some way.

This would also help if the variables are not directly created like this but actually returned from different functions and is not clear which of them is being returned.

To Reproduce

Sample:

main.dart

import 'a.dart' as a;

void main() {
  final aFromA = a.A();
  final list = [A(), A(), A()];
  for (final value in list) {
    
  }
}

class A {}

a.dart

class A {}

Steps to reproduce the behavior:

1. Create an empty project and add both files.
2. Hover over the aFromA variable
3. Hover over value variable
4. Hover over list variable

What happens in all of these cases is displayed below in the screenshot session.

Expected behavior
I expected the type hover to differentiate between A from the main.dart file and from a.dart file.

Screenshots

Aditional info
This info is already shown if you hover the actual constructor.

[dart-github-bot]

Summary: The Dart variable hover feature should display the origin of the type, differentiating between types with the same name from different files. This is important for clarity when dealing with types from different sources, especially when they are not directly created but returned from functions.

[FMorschel]

Just to point out some related (but different) issues:

• Add new "Go to Import" option #56584
• Hovers should show what imports are adding that declaration #56935

[bwilkerson]

When you hover over the constructor the hover text tells you about the constructor, including the library where the constructor is defined. When you hover over the local variable the hover text tells you about the local variable. It doesn't include the library in which the local variable is defined because it's a local variable, there's only one library where it can be defined.

However, neither tell you anything about the type of the element being referenced at the hover site. The library included in the hover for the constructor is telling you where the constructor is defined. Today that happens to be the same as the library in which the class containing the constructor is defined, but if we get static extension methods they might be different.

I'm not saying that we can't consider providing disambiguation information related to types, just explaining how to interpret the current behavior. The implication being that, in my mind at least, this isn't a request for all hovers to display the same information, it's a request for all hovers to display additional information that none of them are currently displaying.

[FMorschel]

I see that now. My original thoughs were to, on the above example, where you have that other import you could see the a. prefixed to A on the hover. I hadn't taken into account that the import could be added twice here and then I'm not sure what we could do.

The original case was something like the following - which would not be solved by the request above as is:

a.dart:

class A {}

b.dart

import 'a.dart';
A foo() => A()

c.dart

import 'b.dart';

class A {}

void main() {
  var a = foo();
  var a2 = A();
}

You can't ever tell where does the a type comes from at all here and it seems to be the same as a2 so when using it inside parameters it gets difficult to understand what is wrong (I have opened #56505 for that as well).

[FMorschel]

Actually, in the above example I gave just now, you could use "go to type definition" but it would only work if you had exactly that variable type (not on lists or whatever else unless you got to that specific declaration that uses the generics).