---
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.
Comment #1 by clugdbug — 2009-07-09T07:23:08Z
The ICE was fixed in DMD2.031. Now it's just a rejects-valid.
Comment #2 by smjg — 2009-08-25T11:17:06Z
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)
Comment #3 by dfj1esp02 — 2009-09-29T02:05:31Z
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;
}
----
Comment #4 by smjg — 2009-09-29T02:45:33Z
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.
Comment #5 by dfj1esp02 — 2009-09-29T04:16:12Z
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.
Comment #6 by r.sagitario — 2010-05-11T13:08:56Z
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());
Comment #7 by r.sagitario — 2010-05-14T09:11:21Z
*** Issue 4186 has been marked as a duplicate of this issue. ***
Comment #8 by schveiguy — 2010-06-16T06:32:44Z
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.
Comment #9 by witold.baryluk+d — 2011-01-02T12:46:04Z
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.
Comment #10 by bearophile_hugs — 2011-01-23T07:17:03Z
Hit by the same bug, the reduced code:
int main() {
return foo();
}
auto foo() {
return 0;
}
Comment #11 by andrei — 2011-01-26T13:25:36Z
Occurs also when using with typeof:
auto fun() { return 1; }
int gun(typeof(fun()) x) { return 2 + x; }
void main()
{
gun(3);
}