fix Issue 314 - static, renamed, and selective imports are always public

[MartinNowak]

• enable protection for imports

Based on DIP22 (#5472) in order to resolve plenty of private/public symbol collisions as in this example.

module b;
import core.stdc.stdio : print; // private printf alias

import core.stdc.stdio; // public printf definition
import b; // private printf alias from selective import

void test() { printf(""); }

Depends On: #5509

[dlang-bot]

Fix	Bugzilla	Description
✓	314	[module] Static, renamed, and selective imports are always public

[WalterBright]

Can this be done as smaller PRs? These giant things are very hard to review. For example, the first commit is a simple refactor, there's no need to lump it in with the rest. Queue all the arguments I made to Kenji about this.

[MartinNowak]

Can this be done as smaller PRs? These giant things are very hard to review. For example, the first commit is a simple refactor, there's no need to lump it in with the rest. Queue all the arguments I made to Kenji about this.

This PR is based on DIP22 (#5472) as mentioned above, so github shows commits from both.
It only consists of a single commit MartinNowak@a8b96b4.

[WalterBright]

If the previous commits are already pulled, why do they show here? I don't understand. Maybe rebase?

[Geod24]

@WalterBright : They aren't pulled yet, #5472 is still open.
When it is merged, they won't show up here anymore (unless some of the commits are changed, in which case it will need a rebase yes). Note that merging this P.R. would also automatically close #5472.

[MartinNowak]

Rebased now and also added a changelog entry @WalterBright.

[MartinNowak]

The eager access checks during lookup are disabled for renamed and selective imports. This is instead handled by the new DIP22 symbolIsVisible check above.
This means that people will only get a deprecation warning for now (b/c of the additional IgnoreSymbolVisibility lookup), and that -transition=import/-transition=checkimports work as for any other private symbol w/ the DIP22 changes.

[MartinNowak]

Fixed the Win64 failure, see #5509.

[MartinNowak]

Rebased on top of the merged BitArray bugfix. The Win32_64 is a bit overwhelmed, can we get this auto-merged once it's reviewed?

[andralex]

Guess it's about time. As I mentioned in email comm, it would be great to integrate all lookup changes under the same scalable -dip22 flag. @MartinNowak @WalterBright thoughts?

[WalterBright]

Auto-merge toggled on

[MartinNowak]

As I mentioned in email comm, it would be great to integrate all lookup changes under the same scalable -dip22 flag.

The can all be turned off/mitigated using -transition=imports/-transition=checkimports. DIP22, 313, and 314 are all implemented as deprecations and shouldn't change the semantic of any currently compiling code.

[JackStouffer]

Does this mean we can finally get rid of the complete imports of modules at the top of every Phobos file?

[MartinNowak]

Does this mean we can finally get rid of the complete imports of modules at the top of every Phobos file?

It means you can safely add selective imports add module level, w/o leaking symbols. Don't jump onto that too fast until the deprecation is over and we remove the -transition=imports.