Bug 9292 – hasNestedArgs wrong result for nested template literal

Status
NEW
Severity
normal
Priority
P3
Component
dmd
Product
D
Version
D2
Platform
All
OS
All
Creation time
2013-01-10T11:25:00Z
Last change time
2024-12-13T18:03:36Z
Assigned to
No Owner
Creator
Johannes Pfau
Moved to GitHub: dmd#18511 →

Attachments

IDFilenameSummaryContent-TypeSize
1178testcase.dtest casetext/x-dsrc342

Comments

Comment #0 by johannespfau — 2013-01-10T11:25:00Z
Created attachment 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?
Comment #1 by ibuclaw — 2013-01-10T12:44:09Z
(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.
Comment #2 by johannespfau — 2013-01-12T10:24:22Z
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.
Comment #3 by robert.schadek — 2024-12-13T18:03:36Z
THIS ISSUE HAS BEEN MOVED TO GITHUB https://github.com/dlang/dmd/issues/18511 DO NOT COMMENT HERE ANYMORE, NOBODY WILL SEE IT, THIS ISSUE HAS BEEN MOVED TO GITHUB