www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.bugs - [Issue 3553] New: ICE when a template function size_t argument defaults to __LINE__

reply d-bugmail puremagic.com writes:
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



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: -------
Nov 26 2009
next sibling parent d-bugmail puremagic.com writes:
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__



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: -------
Nov 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3553


Don <clugdbug yahoo.com.au> changed:

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



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: -------
Nov 26 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3553


Brad Roberts <braddr puremagic.com> changed:

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



---
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: -------
Nov 27 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3553






 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: -------
Dec 01 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3553


Walter Bright <bugzilla digitalmars.com> changed:

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



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: -------
Dec 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3553






 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: -------
Dec 03 2009
prev sibling next sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3553




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: -------
Dec 03 2009
prev sibling parent d-bugmail puremagic.com writes:
http://d.puremagic.com/issues/show_bug.cgi?id=3553


Walter Bright <bugzilla digitalmars.com> changed:

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



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: -------
Dec 06 2009