www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 9292] New: hasNestedArgs wrong result for nested template literal

reply d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9292

           Summary: hasNestedArgs wrong result for nested template literal
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: johannespfau gmail.com


--- Comment #0 from Johannes Pfau <johannespfau gmail.com> 2013-01-10 11:25:00
PST ---
Created an attachment (id=1178)
test case

When compiling testcase.d, hasNestedArgs returns these results:

topNIndex!() nested=0
Test!(indirectLess) nested=1
BinaryHeap!(Test()) nested=0

AFAIK BinaryHeap!(Test()) should also be marked as nested, as it needs
Test!(indirectLess) which is nested?

I'm not sure if this causes a real problem in dmd, but we use
hasNestedArgs/isnested in gdc to tell the backend if the instantiated template
is accessible from other modules.

Therefore this test case currently ICEs gdc (also depends on gcc version. Some
are more picky)

BTW: Would it be OK to mark this as "blocker", as it blocks gdc from compiling
that test case?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Jan 10 2013
next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9292


Iain Buclaw <ibuclaw ubuntu.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ibuclaw ubuntu.com


--- Comment #1 from Iain Buclaw <ibuclaw ubuntu.com> 2013-01-10 12:44:09 PST ---
(In reply to comment #0)
 Created an attachment (id=1178) [details]
 test case
 
 When compiling testcase.d, hasNestedArgs returns these results:
 
 topNIndex!() nested=0
 Test!(indirectLess) nested=1
 BinaryHeap!(Test()) nested=0
 
 AFAIK BinaryHeap!(Test()) should also be marked as nested, as it needs
 Test!(indirectLess) which is nested?
 
 I'm not sure if this causes a real problem in dmd, but we use
 hasNestedArgs/isnested in gdc to tell the backend if the instantiated template
 is accessible from other modules.
 
 Therefore this test case currently ICEs gdc (also depends on gcc version. Some
 are more picky)
 
 BTW: Would it be OK to mark this as "blocker", as it blocks gdc from compiling
 that test case?

IIRC, the way DMD does it, all functions are public, even nested ones. I think I've had this argument before with Alex over whether I should follow suit or carry on marking nested functions as non-public. Call by alias is meant to be a direct call that skips any checks for where the function actually is. So far have been special casing these instances as I find them. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Jan 10 2013
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=9292



--- Comment #2 from Johannes Pfau <johannespfau gmail.com> 2013-01-12 10:24:22
PST ---
What drawback has marking all functions PUBLIC? I guess it'll completely
prevent the backend from removing unreachable nested functions so it's not a
perfect soultion. Although it sounds like a simple & quick solution to a not so
simple problem.

Doesn't detecting such cases in the backend basically mean duplicating the
hasNestedArgs functionality? And I guess the GCC backend doesn't let us skip
those tests, as it seems to chocke on nested, public functions.

We can continue the gdc specific discussion here:
http://gdcproject.org/bugzilla/show_bug.cgi?id=35 but I think we should still
leave this bug open as it's also a bug in the frontend.

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