fix Issue 16085 - wrong visibility warning for overloaded alias symbol

[MartinNowak]

• mark OverDeclaration as overloadable
• mark AliasDeclaration as overloadable (depends on aliasee)
• replace overloadApply with a custom iteration b/c aliases
  must not be resolved for visibility checks (i.e. public aliases to
  private symbols are public)
• deal with the messy overloading of aliasees (see comments)

[dlang-bot]

Fix	Bugzilla	Description
✓	16085	wrong visibility warning for overloaded alias symbol

[MartinNowak]

Doesn't seem to work that way, seem like the function is overloadInserted into the aliasee instead.

[MartinNowak]

Seriously, who came up with the stupid term overnext for nextOverload? It makes thinking about this already messy implementation even harder.

[WalterBright]

I'm a little concerned about this. Consider:

struct S {
  public int foo(int i);
  private int foo(uint u);
}

Overloading is done before access checking, but this change seems to do it after. Overloading is not supposed to be affected by public/private.

[MartinNowak]

Overloading is done before access checking, but this change seems to do it after. Overloading is not supposed to be affected by public/private.

No, this does not affect overloading! Please compare w/ DIP22

The least protected symbol determines the visibility for overloads.
After overload resolution an additional access check will be performed. Thereby overload resolution remains independent of look-up origin.

We've discussed this before (at least I mentioned this behavior several times to you) and it was part of the DIP22 PR.
#5472 (comment)

[MartinNowak]

Properly determining the visibility of overloads w/ mixed protection is the point of this PR.

[MartinNowak]

As the name and comment say, this is just used to determine the combined visibility of overloads. It does not perform any overload resolution.

[MartinNowak]

I plan some refactoring to merge the new visibility mechanism with the old one (limiting visibility of private imports). When this is done, the signature would become bool hasVisibleOverload(Dsymbol s, Scope* sc, Prot visibility), but right now we need to dig out an actual symbol to check.

[MartinNowak]

Thanks