www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - private selective import + overload = breaks accessibility rules

reply rumbu <rumbu rumbu.ro> writes:
module a;

private import std.math: isNaN;

//custom overload
public bool isNaN(int i) { return false; }


=============================

module b;
import a;

void foo()
{
     bool b = isNaN(float.nan);
     //compiles successfully calling std.math.isNaN even it should 
not be visible.
}

Is this normal behavior or a bug?

OK, let's try another:

module b;
import a;
import std.math; // <== note this

void foo()
{
     bool b = isNaN(float.nan);
}

It ends in a very funny error message:

Error: std.math.isNaN!float.isNaN at src\phobos\std\math.d(5335) 
conflicts with std.math.isNaN!float.isNaN at 
src\phobos\std\math.d(5335)

Real life context:

the private import: 
https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L320

the overload:
https://github.com/rumbu13/decimal/blob/master/src/decimal/decimal.d#L4201

If the end user wants to use my module like this:

import std.math;
import decimal;

he'll get the nice error message above.
	
Jan 16
parent reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Tue, Jan 16, 2018 at 06:13:27PM +0000, rumbu via Digitalmars-d-learn wrote:
 module a;
 
 private import std.math: isNaN;
 
 //custom overload
 public bool isNaN(int i) { return false; }
 
 
 =============================
 
 module b;
 import a;
 
 void foo()
 {
     bool b = isNaN(float.nan);
     //compiles successfully calling std.math.isNaN even it should not be
 visible.
 }
 
 Is this normal behavior or a bug?
Which version of the compiler is this? I'm pretty sure the std.math.isNaN imported by module a should not be visible in module b. The latest compiler should emit a deprecation warning for this. Of course, it's possible that having a public symbol in module a that overloads an imported symbol may have triggered a buggy corner case in the compiler. If so, a bug should be filed.
 OK, let's try another:
 
 module b;
 import a;
 import std.math; // <== note this
 
 void foo()
 {
     bool b = isNaN(float.nan);
 }
 
 It ends in a very funny error message:
 
 Error: std.math.isNaN!float.isNaN at src\phobos\std\math.d(5335) conflicts
 with std.math.isNaN!float.isNaN at src\phobos\std\math.d(5335)
[...] LOL! Yeah, if this is the latest compiler, it's definitely a bug. T -- First Rule of History: History doesn't repeat itself -- historians merely repeat each other.
Jan 16
parent reply rumbu <rumbu rumbu.ro> writes:
On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote:

 Which version of the compiler is this?  I'm pretty sure the 
 std.math.isNaN imported by module a should not be visible in 
 module b. The latest compiler should emit a deprecation warning 
 for this.
2.078, but also 2.077. Deprecation is emitted only if there is no overload;
 Of course, it's possible that having a public symbol in module 
 a that overloads an imported symbol may have triggered a buggy 
 corner case in the compiler.  If so, a bug should be filed.
Done: https://issues.dlang.org/show_bug.cgi?id=18243
Jan 16
parent reply Seb <seb wilzba.ch> writes:
On Tuesday, 16 January 2018 at 19:05:51 UTC, rumbu wrote:
 On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote:

 Which version of the compiler is this?  I'm pretty sure the 
 std.math.isNaN imported by module a should not be visible in 
 module b. The latest compiler should emit a deprecation 
 warning for this.
2.078, but also 2.077. Deprecation is emitted only if there is no overload;
 Of course, it's possible that having a public symbol in module 
 a that overloads an imported symbol may have triggered a buggy 
 corner case in the compiler.  If so, a bug should be filed.
Done: https://issues.dlang.org/show_bug.cgi?id=18243
1) Imports are by default private 2) This is a known bug. See: https://github.com/dlang/phobos/pull/5584 https://issues.dlang.org/show_bug.cgi?id=17630 On the good side, there's WIP to fix this, e.g. https://github.com/dlang/dmd/pull/7668
Jan 16
parent reply Joakim <dlang joakim.fea.st> writes:
On Wednesday, 17 January 2018 at 02:23:40 UTC, Seb wrote:
 On Tuesday, 16 January 2018 at 19:05:51 UTC, rumbu wrote:
 On Tuesday, 16 January 2018 at 18:32:46 UTC, H. S. Teoh wrote:

 Which version of the compiler is this?  I'm pretty sure the 
 std.math.isNaN imported by module a should not be visible in 
 module b. The latest compiler should emit a deprecation 
 warning for this.
2.078, but also 2.077. Deprecation is emitted only if there is no overload;
 Of course, it's possible that having a public symbol in 
 module a that overloads an imported symbol may have triggered 
 a buggy corner case in the compiler.  If so, a bug should be 
 filed.
Done: https://issues.dlang.org/show_bug.cgi?id=18243
1) Imports are by default private 2) This is a known bug. See: https://github.com/dlang/phobos/pull/5584 https://issues.dlang.org/show_bug.cgi?id=17630 On the good side, there's WIP to fix this, e.g. https://github.com/dlang/dmd/pull/7668
Are you sure about this? I thought such module-scope selective imports were supposed to be private by default since Martin's fixes for bug 314, which is why you submitted pull 5584. Bug 17630 is about something different, that selective imports pull symbols out of the imported module's non-selective imports, but he's not using any selective imports in his module b. I ran this code example through my symbol-dumping dmd (http://forum.dlang.org/thread/pbpckzwmfglzgwqveoza forum.dlang.org) and module b from his first example is indeed getting isNaN from std.math, which implies the older bug that selective imports at module scope are still leaking out.
Jan 16
parent Seb <seb wilzba.ch> writes:
On Wednesday, 17 January 2018 at 07:40:36 UTC, Joakim wrote:
 Are you sure about this?  I thought such module-scope selective 
 imports were supposed to be private by default since Martin's 
 fixes for bug 314, which is why you submitted pull 5584.  Bug 
 17630 is about something different, that selective imports pull 
 symbols out of the imported module's non-selective imports, but 
 he's not using any selective imports in his module b.

 I ran this code example through my symbol-dumping dmd 
 (http://forum.dlang.org/thread/pbpckzwmfglzgwqveoza forum.dlang.org) and
module b from his first example is indeed getting isNaN from std.math, which
implies the older bug that selective imports at module scope are still leaking
out.
Well the problem is that DMD doesn't perform no checks whatsoever when you do selective imports. So yes, I think both bugs are related. However, I re-opened 18234 as we want to include the test case to the testsuite gets fixed. BTW it's a shame that https://github.com/dlang/dmd/pull/6676 which will be pulled soon while being very close to the bugs in question, doesn't fix either of them.
Jan 17