Jump to page: 1 25  
Page
Thread overview
[Issue 314] New: Static, renamed, and selective imports are always public
Aug 27, 2006
d-bugmail
Jan 23, 2007
d-bugmail
Jan 29, 2007
d-bugmail
Apr 16, 2008
d-bugmail
Apr 17, 2008
d-bugmail
Sep 03, 2008
d-bugmail
May 12, 2009
Christian Kamm
May 13, 2009
Walter Bright
May 13, 2009
Christian Kamm
May 16, 2009
Christian Kamm
Aug 20, 2009
Stewart Gordon
Aug 31, 2009
Matti Niemenmaa
[Issue 314] [module] Static, renamed, and selective imports are always public
May 07, 2010
nfxjfg@gmail.com
May 26, 2010
Trass3r
May 26, 2010
Leandro Lucarella
May 26, 2010
Trass3r
May 27, 2010
Leandro Lucarella
Aug 11, 2010
Don
Aug 12, 2010
Christian Kamm
Aug 12, 2010
Don
Aug 12, 2010
nfxjfg@gmail.com
Aug 12, 2010
Don
Aug 12, 2010
Leandro Lucarella
Aug 12, 2010
Christian Kamm
Aug 12, 2010
Christian Kamm
Aug 12, 2010
Don
Aug 19, 2010
Don
Aug 20, 2010
Christian Kamm
Oct 29, 2010
strtr@despam.it
Nov 04, 2010
strtr@despam.it
Nov 04, 2010
strtr@despam.it
May 29, 2011
Mike Parker
Jul 03, 2011
Christian Kamm
Nov 09, 2011
Leandro Lucarella
Jan 01, 2012
Walter Bright
Jan 02, 2012
Leandro Lucarella
Jan 24, 2012
Don
Jan 30, 2012
Walter Bright
Feb 13, 2012
Walter Bright
Feb 15, 2013
Andrej Mitrovic
Feb 25, 2013
Marco Leise
Jun 25, 2013
Kenji Hara
August 27, 2006
http://d.puremagic.com/issues/show_bug.cgi?id=314

           Summary: Static, renamed, and selective imports are always public
           Product: D
           Version: 0.165
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: accepts-invalid
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: deewiant@gmail.com
 BugsThisDependsOn: 313


In file a.d:
--
// explicit privates unnecessary but added for clarity
version(stat) private static import std.stdio;
version(rena) private import io = std.stdio;
version(sele) private import std.stdio : writefln;
--
In file b.d:
--
import a;

void main() {
        version(stat) std.stdio.writefln("This should not work.");
        version(rena) io.writefln("This should not work.");
        version(sele) writefln("This should not work.");
}
--

Compiled with version=stat, version=rena, or version=sele, the program outputs "This should not work.", when it shouldn't even compile.

Note that the version(stat) case is dependant on Issue 313.


-- 

January 23, 2007
http://d.puremagic.com/issues/show_bug.cgi?id=314





------- Comment #1 from davidl@126.com  2007-01-23 04:30 -------
errr, d 1.0 still has this bug.. but bug 313's example doesn't work any more.


-- 

January 29, 2007
http://d.puremagic.com/issues/show_bug.cgi?id=314


torhu@yahoo.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wbaxter@gmail.com




------- Comment #2 from torhu@yahoo.com  2007-01-29 01:56 -------
*** Bug 604 has been marked as a duplicate of this bug. ***


-- 

April 16, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=314





------- Comment #3 from kamm-removethis@incasoftware.de  2008-04-16 14:29 -------
Created an attachment (id=246)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=246&action=view)
Fix by checking protection attribute for all nonlocal symbols

The patch has been tested rudimentarily on llvmdc. I have commented the two crucial changes.

Even if there is a good reason for not checking the protection attribute of all symbols, it should still be simple to special case this fix for import declarations and the alias declarations generated by them.

Note that

module c;
int var;
--
module b;
import c;
--
module a;
import b;

void main {
  var = 1; // var: undefined identifier (no change)
  c.var = 1; // c: undefined identifier (instead of ok)
  b.c.var = 1; // still ok
}


-- 

April 17, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=314





------- Comment #4 from kamm-removethis@incasoftware.de  2008-04-17 15:26 -------
(In reply to comment #3)
> Created an attachment
> Fix by checking protection attribute for all nonlocal symbols

I aimed a little high; this patch does not add checks for the protection attribute for all nonlocal symbols. It adds checks only for the ones contained in ScopeDsymbol and only in a coarse (public or private) way.

But doing that consistently is a different bug/enhancement anyway. Using a variation of this patch to fix the import issue bugs 313 and 314 describe should still be fine.


-- 

September 03, 2008
http://d.puremagic.com/issues/show_bug.cgi?id=314


jarrett.billingsley@gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sean@invisibleduck.org




------- Comment #5 from jarrett.billingsley@gmail.com  2008-09-02 22:17 -------
*** Bug 2330 has been marked as a duplicate of this bug. ***


-- 

May 12, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=314


Christian Kamm <kamm-removethis@incasoftware.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #246 is|0                           |1
           obsolete|                            |




--- Comment #6 from Christian Kamm <kamm-removethis@incasoftware.de>  2009-05-12 11:22:49 PDT ---
Created an attachment (id=364)
 --> (http://d.puremagic.com/issues/attachment.cgi?id=364)
patch

Ignores nonlocal private symbols when looking up and identifier. Sets the protection attribute of imports and generated aliases to the protection level specified for the import.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 13, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=314





--- Comment #7 from Walter Bright <bugzilla@digitalmars.com>  2009-05-12 19:04:58 PDT ---
Access protection is defined to happen after lookup and overload resolution. Making private symbols invisible defeats this, and also doesn't work as the overload list is a linked list, and making the head of it private would hide the rest of the possibly public overloads.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 13, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=314





--- Comment #8 from Christian Kamm <kamm-removethis@incasoftware.de>  2009-05-13 10:45:04 PDT ---
Thanks for the thorough reply. I disagree that overload resolution happens strictly before access checks. Consider:

a.d --
void foo(int) { printf("foo-i"); }

b.d --
import a : foo;
void foo(float) { printf("foo-f"); }

c.d --
import b;
void main() { int i; foo(i); }

Like this, with dmd 1.043, you get "foo-i". If you remove the selective import of foo, you get "foo-f". Private imports are invisible at lookup-time, but renamed or selective private imports aren't. Therefore it seems to me that making these invisible is the right thing to do.

The patch does have a problem with overloads though and that ought to be fixed. Would you accept a patch that works along the same lines but handles overloads correctly?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
May 16, 2009
http://d.puremagic.com/issues/show_bug.cgi?id=314





--- Comment #9 from Christian Kamm <kamm-removethis@incasoftware.de>  2009-05-16 05:54:34 PDT ---
I've updated the patch. Treating overloads correctly complicated the issue quite a bit. What I've done is to store the import protection in the AliasDeclarations and FuncAliasDeclarations generated by selective and renamed imports. These are then ignored when traversing the overload tree if they are in a different module than the one initiating the traversal.

That means, however, that overload resolution needs to know which module is triggering it and has led to a lot of module passing. :/

I've also made the hiding of private symbols in ScopeDsymbol::search specific to AliasDeclarations generated by ImportStatement. Making the protection attributes apply consistently to more than Func- and VarDecls is a separate issue.

The LDC changesets are:
http://www.dsource.org/projects/ldc/changeset/1358
http://www.dsource.org/projects/ldc/changeset/1362
I can make a patch against DMD if requested.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
« First   ‹ Prev
1 2 3 4 5