argument_type_not_assignable message should show the declaration for typedefs

[FMorschel]

Comming from #56505.

The repro:

typedef MyBadlyNamedTypedef = int Function(int);

void foo(MyBadlyNamedTypedef f) {}

void bar() {
  foo(baz);
}

String baz(int x) => x.toString();

The error message:

The argument type 'String Function(int)' can't be assigned to the parameter type 'MyBadlyNamedTypedef'. 

---

I'd suggest to show the actual type somewhere, replace the typedef or show both with one inside () or something (preferred).

Take my example. If you have a badly named typedef or you are unfamiliar with what it means, this could be really weird.

Also, because of #57013, we still can't "Go to Type Definition" and see the typedef. So for Function types, to find out what it is you'd need to look at the definition for whatever you are trying to assign the Function, so you can see the typedef written down to find its definition (if it is a constructor you could also only see in the propriety definition some classes up the chain with lots of super and one this).

---

@srawlins wrote:

[...] there might be discussion on the messaging. I think it'd be great to show both type aliases and un-aliased actual types. But because of the lengthy message that creates, I think we essentially never do that, and default to the un-aliased types (or maybe it's a mixed bag).

---

@bwilkerson wrote:

To show the actual type somewhere ...

That seems like a reasonable thing to do. I think we should show both.

But because of the lengthy message that creates ...

When we stick the URI of the type in messages to disambiguate them we end up with fairly long messages, but it's better than "Can't assign 'C' to 'C'." style messages.

The alternative that I could imaging is to put the extra information in a context message, something like "The typedef 'MyBadlyNamedTypedef' is equivalent to 'int Function(int)'."

Also, because of #57013, we still can't "Go to Type Definition" and see the typedef.

If the only reason to add this information to the message were because of the lack of navigation, I'd recommend that we fix the navigation and leave the message alone. But the message also gets displayed by the command-line analyzer, so I think that fixing that issue wouldn't impact this one.

[dart-github-bot]

Summary: The error message for type mismatches involving typedefs does not show the actual type of the typedef, making it difficult to understand the error when the typedef name is unclear or unfamiliar. This issue suggests showing both the typedef name and its actual type in the error message to improve clarity.