Skip to content

Comments

fix Issue 15900 - public imports not accessible using FQN#5967

Merged
WalterBright merged 2 commits intodlang:stablefrom
MartinNowak:fix15900
Jul 30, 2016
Merged

fix Issue 15900 - public imports not accessible using FQN#5967
WalterBright merged 2 commits intodlang:stablefrom
MartinNowak:fix15900

Conversation

@MartinNowak
Copy link
Member

  • public imports in imported modules were not accessbile using their
    FQN, this was an oversight when adding the package tree masking to fix
    Bugzilla 313 (see fix Issue 313 - Fully qualified names bypass private imports #5426)
  • fixed by recursively checking imported scopes for accessible packages
  • Uses the same reduced visibility distinction (only private vs. rest) as the
    unqualified symbol search, b/c extending importedScopes to track rich
    visibility (e.g. package(a.b)) was out of scope for a regression fix.
    This should be implemented when combining the search/import w/
    the symbol visibility mechanism.
  • also fixes Issue 16316 - FQN of imports in mixin template not accessible
    by searching the importedScopes for accessible packages

@dlang-bot
Copy link
Contributor

Fix Bugzilla Description
15900 [REG 2.071](Import deprecation) Public import ignored when using fully qualified name
16316 [REG 2.071](Import deprecation) fully qualified name of imports in mixin template not accessible

@MartinNowak
Copy link
Member Author

Need to fix Travis-CI testing of stable branch (it's checking out druntime/phobos) master atm., please ignore the failures, but only this time ;).

@MartinNowak
Copy link
Member Author

Finally fixed all the testing issues with stable, both for Travis-CI and the auto-tester.

@wilzbach
Copy link
Contributor

Finally fixed all the testing issues with stable, both for Travis-CI and the auto-tester.

FYI The windows machines still seem to fail :/

- public imports in imported modules were not accessbile using their
  FQN, this was an oversight when adding the package tree masking to fix
  Bugzilla 313 (see dlang#5426)
- fixed by recursively checking imported scopes for accessible packages
- reuse Module.insearch to not follow import cycles
- Uses the same reduced visibility distinction (only private vs. rest) as the
  unqualified symbol search, b/c extending importedScopes to track rich
  visibility (e.g. package(a.b)) was out of scope for a regression fix.
  This should be implemented when combining the search/import w/
  the symbol visibility mechanism.
- this is also fixed by searching the importedScopes for accessible packages
@WalterBright
Copy link
Member

Auto-merge toggled on

@WalterBright WalterBright merged commit 4caed55 into dlang:stable Jul 30, 2016
@MartinNowak MartinNowak deleted the fix15900 branch August 1, 2016 09:14
@MartinNowak
Copy link
Member Author

FYI The windows machines still seem to fail :/

Got fixed here, had to handle public import cycles.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants