Analyzer should ignore warning on private typedefs

[ChaserVasya]

Snippet

void main() {
  final a = fn();
  print(a);
}

_A fn() {
  return 1;
}

typedef _A = int;

Actual

The typedef is unused in a pop-up about declaration.

And unused in a hint about the variable

A warning is provided

Expected

No warning OR using a typedef in a pop-up window.

Let's imagine that fn places in another file. The declaration pop-up uses int. The variable pop-up uses int. User sees _A only if he goes to the file with fn. So, why the typedef triggers analyzer?

Technically private typedef doesn't used anywhere outside of library.

SDK

Dart SDK version: 3.5.4 (stable) (Wed Oct 16 16:18:51 2024 +0000) on "macos_arm64"

[dart-github-bot]

Summary: Unused private typedef _A triggers warnings in the analyzer despite not being used outside its defining library. The analyzer should ignore unused private typedefs.

[FMorschel]

Somewhat related to #57013 and #39332. If the latter is closed by implementing the request, this issue would not make much sense, I don't think.

CCing @bwilkerson to weigh in on this.

[bwilkerson]

I'm not sure I understand the problem. When I paste the given snippet of code into a file and use the analyzer from main, I don't see any warning. It's possible that there's a lint that's producing a diagnostic that I don't have enabled. Could you tell me what the 'name' of the diagnostic is?

As for the implied question about which UX is better, I tend to think that the primary reason for introducing a typedef is to provide a more semantically meaningful name for a type. If that's true, then it seems like we ought to be using the name of the typedef rather than the underlying type anywhere we can in the UI. So I would say that we should fix the way it's being displayed in hovers, hints, and diagnostics.

[FMorschel]

I do see it library_private_types_in_public_api, @bwilkerson :

typedef _A = int;

_A foo() {         /// library_private_types_in_public_api
  return 0;
}

[bwilkerson]

Thanks! That explains where it's coming from.

In that case I think the diagnostic is valid.

For a longer discussion, see #60028, which this appears to be a duplicate of. I'm going to close this as being a duplicate.