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

           Summary: "void initializer has no value" on struct/union
                    members initialized to "void"
           Product: D
           Version: D2
          Platform: x86_64
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: graham.fawcett@gmail.com


--- Comment #0 from Graham Fawcett <graham.fawcett@gmail.com> 2010-06-15 10:37:45 PDT ---
The following code fails to compile:

struct Foo {
    int[1] a = void;
}
void main() {
    Foo f = Foo();
}

$ dmd err.d
err.d(2): Error: void initializer has no value

Removing the "= void" initializer resolves the issue.
The error is not related to the size of the array, or the element type.

Note that phobos/std/variant.d, line 192, has such a declaration, which causes some variant-using application code to fail with the same error message.

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



--- Comment #1 from Graham Fawcett <graham.fawcett@gmail.com> 2010-06-15 13:15:09 PDT ---
FWIW, removing line 100 in init.c allows simple examples to compile and run correctly. Of course I'm not 100% clear on why the error message was there in the first place. :)

diff --git a/trunk/src/init.c b/trunk/src/init.c
index ed3a091..cf9bc72 100644
--- a/trunk/src/init.c
+++ b/trunk/src/init.c
@@ -97,7 +97,6 @@ Initializer *VoidInitializer::semantic(Scope *sc, Type
*t)

 Expression *VoidInitializer::toExpression()
 {
-    error(loc, "void initializer has no value");
     return new IntegerExp(0);
 }

best,
Graham

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


bearophile_hugs@eml.cc changed:

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


--- Comment #2 from bearophile_hugs@eml.cc 2010-06-15 14:05:06 PDT ---
Answer to Comment 1. You can try to compile this, this must raise an 'void initializer has no value' error still:

void main() {
    void[1] a;
}

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


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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #3 from Don <clugdbug@yahoo.com.au> 2010-06-15 14:55:14 PDT ---
(In reply to comment #1)
> FWIW, removing line 100 in init.c allows simple examples to compile and run correctly. Of course I'm not 100% clear on why the error message was there in the first place. :)
> 
> diff --git a/trunk/src/init.c b/trunk/src/init.c
> index ed3a091..cf9bc72 100644
> --- a/trunk/src/init.c
> +++ b/trunk/src/init.c
> @@ -97,7 +97,6 @@ Initializer *VoidInitializer::semantic(Scope *sc, Type
> *t)
> 
>  Expression *VoidInitializer::toExpression()
>  {
> -    error(loc, "void initializer has no value");
>      return new IntegerExp(0);
>  }
> 
> best,
> Graham

That's too general, the error message is important in other places. I think the
correct fix for the bug, is to allow a void initializer to be used inside
another initializer. This might be a bug in the array literal initializers in
mtype.c, which (from memory) creates an array literal by converting the
initializers to expressions. At least in the case where ALL initializers are
void, the final initializer could also be void.
So the test case should be transformed into:
Foo f = void;
But the simplest solution is probably to change all members into default
initializers, if they are a VoidInitializers.
I recommend to put a breakpoint on the error message and find out where it's
being called from.

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



--- Comment #4 from Graham Fawcett <graham.fawcett@gmail.com> 2010-06-16 06:39:19 PDT ---
Created an attachment (id=664)
proposed patch

When initializing an array, this patch tests whether the initializer is a VoidInitializer, and if so, avoids the toExpression() call. This permits arrays to be initialized "= void".

This compiles and appears to work as expected:

void main() {
  struct foo {
    union {
      char[100] c = void;
      ubyte[100] b
    }
    ubyte[5] good = 44;
    ubyte[5] bad  = void;
  }
  foo f = foo();
  writeln("b ", f.b);
  writeln("c ", f.c);
  writeln("good ", f.good);
  writeln("bad ", f.bad);
}

"good" displays as '44 44 44 44 44', but the void attributes appear uninitialized.

This still fails to compile (as it should):

void main() {
  void[1] a;
}

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



--- Comment #5 from Graham Fawcett <graham.fawcett@gmail.com> 2010-06-16 12:31:07 PDT ---
(In reply to comment #3)
> That's too general, the error message is important in other places. I think the
> correct fix for the bug, is to allow a void initializer to be used inside
> another initializer. This might be a bug in the array literal initializers in
> mtype.c, which (from memory) creates an array literal by converting the
> initializers to expressions. At least in the case where ALL initializers are
> void, the final initializer could also be void.
> So the test case should be transformed into:
> Foo f = void;
> But the simplest solution is probably to change all members into default
> initializers, if they are a VoidInitializers.
> I recommend to put a breakpoint on the error message and find out where it's
> being called from.

Don, you're right. My test case above did not fail through mtype.c, but rather through expression.c (and I've proposed a patch for that). But I was able to produce a similar bug through mtype.c:

import std.stdio;
import std.variant;
import std.algorithm;

void main() {
  foreach (int v; map! "a.get!int" (variantArray(1,2,3)))
    writeln(v);
}

which fails here:

#0  VoidInitializer::toExpression (this=0x9139748) at init.c:100
#1  0x0810047b in TypeStruct::defaultInitLiteral (this=0x8d98ff0, loc=...)
    at mtype.c:6921
#2  0x081039b5 in Type::getProperty (this=0x8d98ff0, loc=..., ident=0x81aec50)
    at mtype.c:1691
#3  0x08102944 in Type::dotExp (this=0x8d98ff0, sc=0x9177c50, e=0x9320c88,
    ident=0x81aec50) at mtype.c:1809
etc.

I'll take a look into mtype.c as well.

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


Graham Fawcett <graham.fawcett@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
 Attachment #664 is|0                           |1
           obsolete|                            |


--- Comment #6 from Graham Fawcett <graham.fawcett@gmail.com> 2010-06-16 12:42:14 PDT ---
Created an attachment (id=665)
patch for mtype.c

This extends my earlier patch by modifying mtype.c as well. I don't have a bare case unfortunately, but this will compile properly with a patched compiler:

import std.algorithm;
import std.variant;
import std.stdio;

void main() {
  foreach (int v; map! "a.get!int" (variantArray(1,2,3)))
    writeln(v);
}

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


Brad Roberts <braddr@puremagic.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Platform|x86_64                      |x86


--- Comment #7 from Brad Roberts <braddr@puremagic.com> 2011-02-06 15:40:39 PST ---
Mass migration of bugs marked as x86-64 to just x86.  The platform run on isn't what's relevant, it's if the app is a 32 or 64 bit app.

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


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

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


--- Comment #8 from Don <clugdbug@yahoo.com.au> 2011-03-01 17:09:41 PST ---
Thanks for the patch, Graham!

https://github.com/D-Programming-Language/dmd/commit/ff143bfa55feb574083b3eae354e87b57c448ffa

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