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

           Summary: ICE on auto function
           Product: D
           Version: 2.027
          Platform: PC
        OS/Version: Windows
            Status: NEW
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: bugzilla@digitalmars.com
        ReportedBy: maxmo@pochta.ru


---
auto a() { return 0; }
static assert(typeof(a).stringof);
---
>Assertion failure: 'global.errors' on line 3845 in file 'mtype.c'

workaround: replace auto with int.


-- 

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|ice-on-valid-code           |rejects-valid
            Summary|ICE(mtype.c) on auto        |Cannot forward reference an
                   |function                    |auto function




--- Comment #1 from Don <clugdbug@yahoo.com.au>  2009-07-09 07:23:08 PDT ---
The ICE was fixed in DMD2.031. Now it's just a rejects-valid.

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


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |smjg@iname.com
            Summary|Cannot forward reference an |Nonsensical forward
                   |auto function               |reference error - stringof
                   |                            |an auto function




--- Comment #2 from Stewart Gordon <smjg@iname.com>  2009-08-25 11:17:06 PDT ---
You forgot to post the error messages.

1.046:
bz2810.d(1): no identifier for declarator a
bz2810.d(1): semicolon expected, not '{'
bz2810.d(1): Declaration expected, not '{'
bz2810.d(1): unrecognized declaration

2.031:
bz2810.d(2): Error: forward reference to a
bz2810.d(2): Error: forward reference to inferred return type of function call
(())()

(Windows)

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


Sobirari Muhomori <maxmo@pochta.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Nonsensical forward         |Forward reference to an
                   |reference error - stringof  |auto function
                   |an auto function            |


--- Comment #3 from Sobirari Muhomori <maxmo@pochta.ru> 2009-09-29 02:05:31 PDT ---
Seems like this is a general forward reference bug, not specific to stringof.
----
void fun()
{
    gun(); //Error: forward reference to gun
}
auto gun()
{
    return 1;
}
----

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


Stewart Gordon <smjg@iname.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |spec


--- Comment #4 from Stewart Gordon <smjg@iname.com> 2009-09-29 02:45:33 PDT ---
But there is no forward reference in the original testcase.  I think what you've just described is a completely separate bug.

BTW I've just checked the spec (both D1 and D2), and it appears that functions with auto return type aren't meant to work, so maybe this technically isn't rejects-valid after all.

Decl:
        StorageClasses Decl
        BasicType Declarators ;
        BasicType Declarator FunctionBody
    AutoDeclaration

AutoDeclaration:
    StorageClasses Identifier = AssignExpression ;

But this seems an arbitrary restriction, given that you can create autotype functions using literals.

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



--- Comment #5 from Sobirari Muhomori <maxmo@pochta.ru> 2009-09-29 04:16:12 PDT ---
A completely separate bug is actually what you described :) Auto functions are obviously supported, I'm not sure if it's still valid to treat the auto keyword as a storage class, if I'm not mistaken long ago it was meant to behave differently.

The forward reference bugs are deeper than you think. The term "forward reference" was taken from C world, the fact is compiler does things in an order, and when at a certain step you need a result of a subsequent step, you get into trouble. In C this situation happened for forward references in lexical sense, because C compiler does things in lexical order. While D compiler can first parse function signatures and then - function bodies, this trick doesn't work for auto functions because their signatures can't be resolved without compilation of the body, so their return types can be accessible only at the end of semantic analysis. D compiler doesn't have lexical forward reference bugs (except for the case of mixin) when you get "undefined identifier" errors, but the compilation order is still here.

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


Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                 CC|                            |r.sagitario@gmx.de


--- Comment #6 from Rainer Schuetze <r.sagitario@gmx.de> 2010-05-11 13:08:56 PDT ---
I just stumbled over this issue, too. What needs to done is to infer the return type of the function (calling semantic3 on the function at a rather early stage of compilation). Here's the patch:

Index: expression.c ===================================================================
--- expression.c    (revision 483)
+++ expression.c    (working copy)
@@ -2448,6 +2448,9 @@

         if (!f->originalType && f->scope)       // semantic not yet run
             f->semantic(f->scope);
+        // if inferring return type, sematic3 needs to be run
+        if(f->inferRetType && f->type && !f->type->nextOf())
+            f->semantic3(f->scope);
         if (!f->type->deco)
         {
             error("forward reference to %s", toChars());

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


Rainer Schuetze <r.sagitario@gmx.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bearophile_hugs@eml.cc


--- Comment #7 from Rainer Schuetze <r.sagitario@gmx.de> 2010-05-14 09:11:21 PDT ---
*** Issue 4186 has been marked as a duplicate of this issue. ***

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


Steven Schveighoffer <schveiguy@yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |schveiguy@yahoo.com


--- Comment #8 from Steven Schveighoffer <schveiguy@yahoo.com> 2010-06-16 06:32:44 PDT ---
I just hit this issue too.

I think the ultimate test for this should be:

auto foo()
{
  bar();
  return 1;
}

auto bar()
{
  foo();
  return 1;
}

Is this possible?  It may be too complex, even though the above should be possible.

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


Witold Baryluk <baryluk@smp.if.uj.edu.pl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baryluk@smp.if.uj.edu.pl


--- Comment #9 from Witold Baryluk <baryluk@smp.if.uj.edu.pl> 2011-01-02 12:46:04 PST ---
Hi,

I also have similar problem, but involving two modules. Minimal test case (it also appears when functions are templates, or returns templated classes, or int type is changed to other type):

/*****************************/
module m2;

auto f(int x) {
   return x;
}

auto g(int x) {
   return f(x);
}
/*****************************/


/*****************************/
module m1;

import m2 : g;

void main() {
   g(5);
}
/*****************************/

It currently depend on the order of files given to the compiler.

# dmd2  m1.d m2.d         # error
m1.d(6): Error: forward reference to g
# dmd2  m2.d m1.d         # works!
#


# dmd2 -c m1.d             # error
m1.d(6): Error: forward reference to g
# dmd2 -c m2.d             # works
#

As one can see there is actually NO forward references here. So I think it is simpler than co-recursive version of Steven. Bug disappears when function f and g, are moved to module m1. Or when function g have explicit return type.

It maybe also related to the bug involving order of files on command line to the compiler.

Thanks.

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