New assist to add/edit hide at import for ambiguous import

[FMorschel]

This issue is to track https://dart-review.googlesource.com/c/sdk/+/386020.

This change would add a new quick-fix option to ambiguous_import to add a hide combinator (or edit the current one to edit it). So cases like:

a.dart

class A {}

b.dart

class A {}

class B {}

c.dart

import 'a.dart';
import 'b.dart' hide B;

void foo(A a) {}      // <-- ambiguous_import

Would trigger this fix options to add hide to 'a.dart' or to edit the hide at 'b.dart'.

---

CC: @bwilkerson

[dart-github-bot]

Summary: This issue proposes a new quick-fix for ambiguous imports. It suggests adding a "hide" combinator to the import statement to resolve the ambiguity, either by adding a new "hide" or editing an existing one.

[bwilkerson]

It's possible for an ambiguous name to be imported through more than 2 imports. For example, given three libraries, L1, L2, and L3, that all define a class named C, a fourth library L4 could import the first three. Hiding the name in one import will only partially solve the problem (by reducing the number of ambiguous names).

Probably more common is that a single definition of the ambiguous name might be imported from multiple libraries. For example, given the libraries, L1 and L2, that both define a class named C, a library L3 that exports L1, and a library L4 that imports the first three, adding a hide to the import of either L1 or L3 won't actually improve the situation at all because the name will still be imported via the other.

That raises a question about the DX.

Rather than require the user to select one fix for every import that should have a hide added to it (potentially a multi-step process), I wonder whether it might be better to have the fix be framed in terms of choosing the one import from which the name shouldn't be hidden, and just hide the name in all the other locations.

Or maybe the set of imports from which it shouldn't be hidden, such as in the second example, where there's no point in hiding it from either L1 or L3 if the declaration in L1 is the one the user wants to use.

Or maybe what's important isn't the import(s) to be unchanged, but the declaration (element in API terms) to be used. Although identifying the declaration might be tricky because the defining library might be an internal library that the user wouldn't recognize.

Of maybe those scenarios are too complex and we should just not offer the fix in those cases.

Curious to hear your thoughts.

[FMorschel]

Rather than require the user to select one fix for every import that should have a hide added to it (potentially a multi-step process), I wonder whether it might be better to have the fix be framed in terms of choosing the one import from which the name shouldn't be hidden, and just hide the name in all the other locations.

Yes, thank you for the suggestion. I hadn't thought of the multi-step process.

However, I believe this would probably be hard to happen unless multiple libraries which export (say L2 exports L1) each other (or something similar) suddenly received a new declaration (say you declare E in L1) with the same name as a declaration in another library (L3) set somewhere else. In this case, if some library (L4) had imported all of the previous as you mentioned, this could happen, otherwise, I think it would be very unlikely that someone had this kind of problem.

---

Or maybe what's important isn't the import(s) to be unchanged, but the declaration (element in API terms) to be used. Although identifying the declaration might be tricky because the defining library might be an internal library that the user wouldn't recognize.

Yes, I do believe that this is ideal. The error message for ambiguous_import already shows all declarations for every element that is coinciding so maybe that would be a possible solution but probably not necessarily easy for the user since, as you mentioned, some of the time the person can be unfamiliar with the declaration itself but they would of course be familiar with the import that they want to keep using it from.

If we had something like the "Docs side panel" (not sure what to call that) that we have for auto-complete options, in assists, we could show the element in the assist text and make sure our user was aware of which imports was it coming from. But since that is not the case I don't believe this would be a good option.

---

Or maybe the set of imports from which it shouldn't be hidden, such as in the second example, where there's no point in hiding it from either L1 or L3 if the declaration in L1 is the one the user wants to use.

Although I see your very valid point here, I don't believe it would be easy for everyone to understand why more than one import was left without the hide. And it would probably make no difference for them if the "other imports" (the ones that export the same element) had the hide added since it wouldn't change their code in any way.

---

While I prefer the "hide every other import" option, I was wondering what should we do in cases where one of the other imports is showing some elements or even the specific element in question. Should we not offer support in those cases? Wondering because it might be tricky to tell the user about that unless we change the error message for ambiguous_import and make sure it also informs the user about the show in the current imports or something else along these lines.