http://d.puremagic.com/issues/show_bug.cgi?id=314



--- Comment #20 from Don <clugdbug@yahoo.com.au> 2010-08-12 01:04:26 PDT ---
(In reply to comment #19)
> Don, which version of the patch did you apply - the one attached here or the one I applied to LDC? Selective imports work correctly in LDC, so maybe there's some extra work needed for D2. I also expect the patch to require some work with regard to overload resolution, it works differently in D2.

The one attached here. Although I've found some problems with selective imports, I no longer think they are the fault of this patch. For example, the existing release of D1 doesn't like this example:
---
import std.stdio : writefln;
void main() {
   std.stdio.writefln("xyz");
}

test0.d(338): Error: undefined identifier std
Error: no property 'writefln' for type 'TOK149'
test0.d(338): Error: function expected before (), not __error of type TOK149
---
After applying the patch and my change to Id::object, and fixing a bug in each of druntime, Phobos, and the test suite, all Phobos unittests pass, and the DMD test suite passes all tests. Looks great to me.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314



--- Comment #21 from nfxjfg@gmail.com 2010-08-12 06:11:44 PDT ---
In my understanding, "import std.stdio : writefln;" only imports the name "writefln", not "std" and "writefln". If the user wants "std", he has to write "static import std.stdio;". I would assume your example is invalid and is expected to fail.

Why would the user do "import std.stdio : writefln;" if he doesn't use writefln directly? Is "std.stdio.writefln" the only name he's supposed to be able to use here? If yes, what the hell is the use of that?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314



--- Comment #22 from Don <clugdbug@yahoo.com.au> 2010-08-12 07:09:34 PDT ---
(In reply to comment #21)
> In my understanding, "import std.stdio : writefln;" only imports the name "writefln", not "std" and "writefln". If the user wants "std", he has to write "static import std.stdio;". I would assume your example is invalid and is expected to fail.
> 
> Why would the user do "import std.stdio : writefln;" if he doesn't use writefln directly? Is "std.stdio.writefln" the only name he's supposed to be able to use here? If yes, what the hell is the use of that?

It's invalid code. But you should never see TOKxxx in an error message. It indicates something is fouled up.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314



--- Comment #23 from Leandro Lucarella <llucax@gmail.com> 2010-08-12 07:25:12 PDT ---
(In reply to comment #22)
> (In reply to comment #21)
> > In my understanding, "import std.stdio : writefln;" only imports the name "writefln", not "std" and "writefln". If the user wants "std", he has to write "static import std.stdio;". I would assume your example is invalid and is expected to fail.
> > 
> > Why would the user do "import std.stdio : writefln;" if he doesn't use writefln directly? Is "std.stdio.writefln" the only name he's supposed to be able to use here? If yes, what the hell is the use of that?
> 
> It's invalid code. But you should never see TOKxxx in an error message. It indicates something is fouled up.

One more for bug 4329 =)

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314



--- Comment #24 from Christian Kamm <kamm-removethis@incasoftware.de> 2010-08-12 10:33:50 PDT ---
(In reply to comment #20)
> (In reply to comment #19)
> > Don, which version of the patch did you apply - the one attached here or the one I applied to LDC?
> 
> The one attached here.

Well, ass Walter pointed out the attached patch has problems with overload resolution. The corrected patch doesn't though. If you're interested in looking at it, I could make it work against the D2 frontend and post it here.

I don't want the effort to be in vain though, so could you check with Walter whether he'd accept a patch that works as described in comment #9?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314



--- Comment #25 from Christian Kamm <kamm-removethis@incasoftware.de> 2010-08-12 10:45:00 PDT ---
Gah, can you edit comments somehow? That typo is extremely embarrassing.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314


Don <clugdbug@yahoo.com.au> changed:

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


--- Comment #26 from Don <clugdbug@yahoo.com.au> 2010-08-12 12:08:52 PDT ---
(From update of attachment 364)
Marking this patch as obsolete, since it is not correct.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314



--- Comment #27 from Don <clugdbug@yahoo.com.au> 2010-08-19 07:39:48 PDT ---
(In reply to comment #24)
> (In reply to comment #20)
> > (In reply to comment #19)
> > > Don, which version of the patch did you apply - the one attached here or the one I applied to LDC?
> > 
> > The one attached here.
> 
> Well, as Walter pointed out the attached patch has problems with overload resolution. The corrected patch doesn't though. If you're interested in looking at it, I could make it work against the D2 frontend and post it here.
> 
> I don't want the effort to be in vain though, so could you check with Walter whether he'd accept a patch that works as described in comment #9?

From discussion with Walter --
It's too difficult to evaluate the patch in its present form. It's in two
parts, both diffed against the LDC codebase rather than DMD, and the context is
really unclear -- it's not clear which functions are being patched. I don't
think a complete patch is required for evaluation -- in fact, a complete patch
would be  more difficult to quickly understand. But if you can write the
essence of the code here, which I think is really only a couple of functions,
that should be enough. And with a explanation of what it's doing. Leave out the
myriad of changes which are just passing the module handle around.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314



--- Comment #28 from Christian Kamm <kamm-removethis@incasoftware.de> 2010-08-20 07:48:05 PDT ---
> But if you can write the
> essence of the code here, which I think is really only a couple of functions,
> that should be enough.

AliasDeclaration and FuncAliasDeclaration get a new 'importprot' member which is set for aliases generated by the import declaration and stores the import's protection.

In ScopeDSymbol::search, we discard aliases which shouldn't be accessible -
unless it's a FuncAliasDeclaration, to avoid making a chain invisible because
the first member is privately imported:
+    // hide the aliases generated by selective or renamed private imports
+    if (s && flags & 1)
+        if (AliasDeclaration* ad = s->isAliasDeclaration())
+        // may be a private alias to a function that is overloaded. these
+        // are sorted out during overload resolution, accept them here
+        if (ad->importprot == PROTprivate &&
!ad->aliassym->isFuncAliasDeclaration())
+        s = NULL;

And for overload resolution, skip over functions that should be invisible:
-int overloadApply(FuncDeclaration *fstart,
+int overloadApply(Module* from, FuncDeclaration *fstart,
     int (*fp)(void *, FuncDeclaration *),
     void *param)
...
     if (fa)
     {
-        if (overloadApply(fa->funcalias, fp, param))
-        return 1;
+        if (fa->getModule() == from || fa->importprot != PROTprivate)
+        if (overloadApply(from, fa->funcalias, fp, param))
+            return 1;
         next = fa->overnext;

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

http://d.puremagic.com/issues/show_bug.cgi?id=314


strtr@despam.it changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |strtr@despam.it


--- Comment #29 from strtr@despam.it 2010-10-28 22:26:20 PDT ---
Frelling bug got me again :(

Any progress?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------