Fix Issue 15896 - private ignored when import bindings are used#6660
Fix Issue 15896 - private ignored when import bindings are used#6660dlang-bot merged 1 commit intodlang:masterfrom
Conversation
|
|
Oops! It seems that there are some phobos bugs. |
|
Can you submit some Phobos PRs to fix this? |
|
@WalterBright done. |
|
@CyberShadow looks like DAutoTest is stuck with the older version of Phobos.Could you please look into this? thx! |
There is nothing wrong with DAutoTest. This PR breaks building dlang.org because the compiler can no longer build the stable version of Phobos. The correct course of action is to perform all breaking changes via a deprecation cycle lasting at least one major version. CC @MartinNowak |
This is not a deprecation, it's "allow invalid". But point taken. @RazvanN7 let's put this on the backburner until the Phobos version gets seasoned. |
|
@andralex: Pretty much all of the 313/314 fallout was accepts-invalid, but we still went through a deprecation process to reduce pain for users. It seems like adding a deprecation message here would be particularly easy anyway? |
|
Aaaand master is broken. |
| { | ||
| Dsymbol s = mod.search_correct(names[i]); | ||
| if (s) | ||
| { |
There was a problem hiding this comment.
single line statement get no braces
|
@RazvanN7 According to @andralex's advice let's revert this until Phobos version gets rolled over or someone submits an implementation that makes the breakage non-fatal (i.e. as a deprecation). Will also set DAutoTest as mandatory for the dmd repo too to prevent such breakages at least until dlang/dlang-bot#69 is fixed. It's also worth looking at the project tester results, as it seems this did in fact cause breakages outside of Phobos (in vibe.d at least). |
|
Sorry folks I was under the assumption "no red buttons pressed no master breakage". Thx @CyberShadow for working on this. I'll be on the road for the next 3 days with scant connectivity. |
A module member which is declared private should not be accessible from another module. While this is true for most members, it is false in the case of variables which are selectively imported. See example in the filed bug report [1]. Although the simplest fix would have been to add a call to the checkAccess function from access.d, this is not possible (see [2]).
When a selective import occurs, the compiler just checks if the selected symbol exists in the imported module; the protection attribute is verified later, when the symbol is used. I think this is a design flaw since you can import a symbol, use it 10 times and have 10 errors, basically stating the same thing. It makes a lot more sense to check if the symbol is private when the existence lookup occurs (and that is what this PR does).
[1] https://issues.dlang.org/show_bug.cgi?id=15896
[2] https://issues.dlang.org/show_bug.cgi?id=1161