www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 11724] New: D emits failed template instantiations

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

           Summary: D emits failed template instantiations
           Product: D
           Version: D2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody puremagic.com
        ReportedBy: ibuclaw ubuntu.com


--- Comment #0 from Iain Buclaw <ibuclaw ubuntu.com> 2013-12-11 00:39:19 PST ---
It would be nice of the front-end to not emit the following code to object
file, especially so as.

1) Both functions share the same symbol (collision detection doesn't work in
__traits code?)
2) Both functions failed semantic analysis.

---
module failsemantic;

template foo10083a(T)
{
    int foo10083a(double) { return 1; }
    int foo10083a(T) { return 2; }
}

static assert(!__traits(compiles, foo10083a!double(1)));
static assert(!__traits(compiles, foo10083a!double(1.0)));


---
Disassembly:
---
Disassembly of section
.text._D12failsemantic16__T9foo10083aTdZ9foo10083aFNaNbNfdZi:

0000000000000000 <_D12failsemantic16__T9foo10083aTdZ9foo10083aFNaNbNfdZi>:
   0:    55                       push   %rbp
   1:    48 8b ec                 mov    %rsp,%rbp
   4:    48 83 ec 10              sub    $0x10,%rsp
   8:    b8 01 00 00 00           mov    $0x1,%eax
   d:    c9                       leaveq 
   e:    c3                       retq   
   f:    90                       nop

0000000000000010 <_D12failsemantic16__T9foo10083aTdZ9foo10083aFNaNbNfdZi>:
  10:    55                       push   %rbp
  11:    48 8b ec                 mov    %rsp,%rbp
  14:    48 83 ec 10              sub    $0x10,%rsp
  18:    b8 02 00 00 00           mov    $0x2,%eax
  1d:    c9                       leaveq 
  1e:    c3                       retq   
  1f:    90                       nop

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 11 2013
next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11724


yebblies <yebblies gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yebblies gmail.com


--- Comment #1 from yebblies <yebblies gmail.com> 2013-12-12 01:17:07 EST ---
Actually, the functions pass semantic just fine.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11724



--- Comment #2 from yebblies <yebblies gmail.com> 2013-12-12 02:24:33 EST ---
The fix here is to not emit speculative templates, but unfortunately this will
need some work in dmd.


void foo()() {}
void bar()() { foo(); }

static assert(is(typeof(bar()))); // marks foo!() and bar!() as speculative

void main()
{
    bar(); // unmarks bar!()
    // foo(); // without this line foo!() is still speculative.
}

So we need a way to detect speculativeness depending on another template
instance.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
Dec 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11724



--- Comment #3 from Kenji Hara <k.hara.pg gmail.com> 2013-12-11 07:44:07 PST ---
(In reply to comment #2)
 The fix here is to not emit speculative templates, but unfortunately this will
 need some work in dmd.
 
 
 void foo()() {}
 void bar()() { foo(); }
 
 static assert(is(typeof(bar()))); // marks foo!() and bar!() as speculative
 
 void main()
 {
     bar(); // unmarks bar!()
     // foo(); // without this line foo!() is still speculative.
 }
 
 So we need a way to detect speculativeness depending on another template
 instance.
Related: issue 10920 Calculating complete dependent graph between template instances during compilation, is the really needed feature in order to kill -allinst switch. But, I'm still not sure how to do it efficiently... -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 11 2013
prev sibling next sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11724



--- Comment #4 from Iain Buclaw <ibuclaw ubuntu.com> 2013-12-11 08:10:23 PST ---
(In reply to comment #1)
 Actually, the functions pass semantic just fine.
Yeah... I cracked open a debugger after raising this and realised the same. Fails compilation in CallExp::semantic, *after* it has been added to the module members list. I poked about with omitting declared members when __traits(compiles) fails, then omitting from within SCOPEstaticassert - but it seems that in both cases causes *needed* symbols to be skipped leading to undefined symbol linker errors. Though I'm not immediately sure why symbols instantiated from static assert() or __traits(compiles) would be needed, unless of course my poking about was all wrong and had the adverse effect of: static if (__traits(compiles, foo!double())) // instantiated and discarded. { return foo!double(); // instantiated, but not added to members. } -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 11 2013
prev sibling parent d-bugmail puremagic.com writes:
https://d.puremagic.com/issues/show_bug.cgi?id=11724



--- Comment #5 from yebblies <yebblies gmail.com> 2013-12-12 04:16:13 EST ---
(In reply to comment #4)
 
 I poked about with omitting declared members when __traits(compiles) fails,
 then omitting from within SCOPEstaticassert - but it seems that in both cases
 causes *needed* symbols to be skipped leading to undefined symbol linker
 errors.  Though I'm not immediately sure why symbols instantiated from static
 assert() or __traits(compiles) would be needed, unless of course my poking
 about was all wrong and had the adverse effect of:
 
See my second comment for why you get linker errors when skipping toObjFile on speculative instances. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email ------- You are receiving this mail because: -------
Dec 11 2013