Created attachment 1164
the source
On compiling with the `-debug' option, i.e. initializing the variable, the
compiler evokes an exception.
Without `-debug', i.e. _not_ initializing the variable, compilation ends
flawlessly.
-manfred
Comment #1 by bearophile_hugs — 2012-11-22T04:21:03Z
Is this a valid reduction of your code?
class Foo {
int bar() {
return 0;
}
int x = bar();
}
void main() {}
Comment #2 by svv1999 — 2012-11-22T04:42:51Z
My text seems to be lost. Retry:
On compiling with `-debug' dmd 2.060 evokes an exception on winXp x86 with all updates.
Without `-debug', i.e without initializing the variable, no comülaints.
-manfred
Comment #3 by svv1999 — 2012-11-22T05:09:15Z
(In reply to comment #1)
> Is this a valid reduction of your code?
> int bar() {
> int x = bar();
Not at first glance.
1)
In your code the missing `this' is declared as the root of the bug report. In my code `this' is present.
2)
In your code reversing the lexical sequence of call and declaration does not change the error message. In my code reversing eliminates the bailing out. In addition no error is reported.
-manfred
Comment #4 by timon.gehr — 2012-11-23T05:53:32Z
Reduced test case:
class C{
enum a=this.b;
auto b(){ return 0; }
}
Comment #5 by clugdbug — 2013-01-04T02:00:12Z
This is not a CTFE bug. Here is an example which doesn't use CTFE, properties, or invalid use of 'this':
---
class C
{
enum a = typeof(this.b()).init;
static auto b(){ return 0; }
}
---
If in any of these examples you replace this.b() by simply b(), you get a "forward reference to b" error message.
Here's a basic patch to do the same thing in this case. I'm not really happy with it though, the errors for b() and this.b() should be generated in the same function.
-- a/src/expression.c
+++ b/src/expression.c
@@ -929,6 +929,11 @@ Type *functionParameters(Loc loc, Scope *sc, TypeFunction *tf,
if (!tf->next && fd->inferRetType)
{
TemplateInstance *spec = fd->isSpeculative();
+ if ( fd->semanticRun < PASSsemanticdone )
+ { // We haven't run semantic() yet, eg bug 9055.
+ error(loc, "forward reference to %s", fd->toChars());
+ return Type::terror;
+ }
int olderrs = global.errors;
// If it isn't speculative, we need to show errors
unsigned oldgag = global.gag;
Comment #6 by clugdbug — 2013-01-04T02:04:17Z
Better test case:
class Bug9055
{
typeof( Bug9055.b() ) x;
auto b(){ return 0; }
}
Comment #7 by timon.gehr — 2013-01-04T10:22:07Z
(In reply to comment #5)
> This is not a CTFE bug. Here is an example which doesn't use CTFE, properties,
> or invalid use of 'this':
> ---
> class C
> {
> enum a = typeof(this.b()).init;
> static auto b(){ return 0; }
> }
>
> ---
> If in any of these examples you replace this.b() by simply b(), you get a
> "forward reference to b" error message.
>
But forward references are allowed. This is another bug.
> Here's a basic patch to do the same thing in this case. I'm not really happy
> with it though, the errors for b() and this.b() should be generated in the same
> function.
> ...
Both cases are valid D code. No error should be generated in either case.
Comment #8 by bugzilla — 2013-10-06T23:59:42Z
The attachment code:
---------------------------
import std.array: Appender;
class Silent{
debug
private Appender!string retval= this.ini;
else
private Appender!string retval;
auto ini(){
return Appender!string("");
}
}
void main(){
}
--------------------------
dmd test
test.d(8): Error: constructor std.array.Appender!string.Appender.this (char[] arr) is not callable using argument types (string)
dmd test -debug
test.d(8): Error: constructor std.array.Appender!string.Appender.this (char[] arr) is not callable using argument types (string)
---------------------------
No seg faults on this or the other examples. If there's some other issue, please open a separate issue.