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

           Summary: ICE when a template function size_t argument defaults
                    to __LINE__
           Product: D
           Version: 2.036
          Platform: Other
        OS/Version: Windows
            Status: NEW
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: snake.scaly@gmail.com


--- Comment #0 from Sergey Gromov <snake.scaly@gmail.com> 2009-11-26 15:46:08 PST ---
The following code:

------8<---------
void foo(T)(size_t line = __LINE__) {}
void main() { foo!char(); }
------8<---------

when compiled, causes an internal compiler error:

>dmd2 -c test.d
__LINE__
Internal error: e2ir.c 652

Workaround: declare line as int.

-- 
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=3553


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au
            Summary|ICE when a template         |ICE when a function
                   |function size_t argument    |argument defaults to
                   |defaults to __LINE__        |__LINE__


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2009-11-26 16:33:26 PST ---
It doesn't need to be a template. It crashes whenever there's an implicit cast from __LINE__ to any non-int type, in a function default argument.

void foo(uint line = __LINE__) {}
void main() { foo(); }

-- 
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=3553


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch


--- Comment #2 from Don <clugdbug@yahoo.com.au> 2009-11-26 23:55:23 PST ---
There are two issues. One is that this use of __LINE__ is a very special case.

The code in Parser::parseDefaultInitExp() in parse.c is unlikely to be correct -- it only treats a default of __LINE__ specially; __LINE__+0 does NOT become a LineInitExp.

But, without changing that, the immediate problem is in expression.c, functionParameters(), around line 670.

The lineInitExp only gets resolved if it's unaltered. But, it might
have been implicitly cast. This patch fixes that.
A more complete fix would change parse.c to allow arbitrary use of __LINE__,
and to resolve recursively in expression.c looking for LineInitExp's. But
that's a pretty obscure feature; this patch is enough to fix the ICE.

Index: expression.c ===================================================================
--- expression.c    (revision 267)
+++ expression.c    (working copy)
@@ -667,7 +667,13 @@
         }
         arg = p->defaultArg;
 #if DMDV2
-        if (arg->op == TOKdefault)
+        if (arg->op == TOKcast && ((CastExp*)arg)->e1->op == TOKdefault)
+        {   // The default value may have been implicitly cast
+            arg = arg->copy();
+            CastExp * def = (CastExp*)arg;
+            def->e1 = ((DefaultInitExp *)(def->e1))->resolve(loc, sc);
+        }
+        else if (arg->op == TOKdefault)
         {   DefaultInitExp *de = (DefaultInitExp *)arg;
             arg = de->resolve(loc, sc);
         }

-- 
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=3553


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |braddr@puremagic.com


--- Comment #3 from Brad Roberts <braddr@puremagic.com> 2009-11-27 00:22:00 PST ---
Hrm.. what's that entire block of code in the 'if' doing?  TOKfile and TOKline are handled down through the layers of expression parsing (primarily in parsePrimaryExp) just fine, from a quick study of the code.  I haven't tried just killing that block to see what happens.  Might it be better to change the two parts of parsePrimaryExp to create FileInitExp and LineInitExp's rather than StringExp and IntegerExp's respectively?

-- 
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=3553



--- Comment #4 from Don <clugdbug@yahoo.com.au> 2009-12-01 11:17:08 PST ---
(In reply to comment #3)
> Hrm.. what's that entire block of code in the 'if' doing?  TOKfile and TOKline are handled down through the layers of expression parsing (primarily in parsePrimaryExp) just fine, from a quick study of the code.

That block is dealing with __LINE__ as a default parameter. In that case only, __LINE is the line that the function is instantiated in, rather than the line it appeared in. So the other uses of TOKfile and TOKline are completely different.

> Might it be better to change the
> two parts of parsePrimaryExp to create FileInitExp and LineInitExp's rather
> than StringExp and IntegerExp's respectively?

FileInitExp, LineInitExp are only handled when they're a default function parameter. Lots of stuff would need to change if they were used throughout.

Basically, the whole thing seems to be a quick hack to get int line = __LINE__ working as a default parameter, which is by far the most important use case. Dealing with the more complicated, obscure cases would be *much* more work.

-- 
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=3553


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com


--- Comment #5 from Walter Bright <bugzilla@digitalmars.com> 2009-12-03 10:58:28 PST ---
I think this is better done with a virtual function. Changeset 280.

-- 
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=3553



--- Comment #6 from Don <clugdbug@yahoo.com.au> 2009-12-03 11:41:26 PST ---
(In reply to comment #5)
> I think this is better done with a virtual function. Changeset 280.

Great! Why not BinExp::resolveLoc() too?

-- 
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=3553



--- Comment #7 from Walter Bright <bugzilla@digitalmars.com> 2009-12-03 12:01:33 PST ---
Mainly because the way it is parsed, I don't think it could ever happen at the moment.

-- 
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=3553


Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #8 from Walter Bright <bugzilla@digitalmars.com> 2009-12-06 00:55:20 PST ---
Fixed dmd 2.037

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