floating-point array size accepted by dmd 0.128

[braddr at puremagic.com]

In article <dd2i4g$1k0g$2 at digitaldaemon.com>, =?ISO-8859-1?Q?Thomas_K=FChne?=
says...
>
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>zwang schrieb:
>
>> void main(){
>>     int[0.128] a; // should not compile
>> }
>
>Added to DStress as
>http://dstress.kuehne.cn/nocompile/o/opIndex_05.d
>
>Thomas
>-----BEGIN PGP SIGNATURE-----
>
>iD8DBQFC9LPj3w+/yD4P9tIRAkdOAJsGrGqjvvdj6w3EUBfBRFAVnrq7SACfbPxu
>tEO9MvFFapIq291Z29Lro+c=
>=XpLM
>-----END PGP SIGNATURE-----

Reviving a very old bug.. In the process of updating gdc, I ran across this one
due to it now causing a segv during a late phase of compilation.  I should
probably find the root cause, but fixing the semantics phase so that this isn't
allowed would also fix it.

The problem is here in dmd/mtype.c:

1622         dim = dim->semantic(sc);
1623         dim = dim->constFold();
1624         integer_t d1 = dim->toInteger();
1625         dim = dim->castTo(tsize_t);
1626         dim = dim->constFold();
1627         integer_t d2 = dim->toInteger();
1628 
1629         if (d1 != d2)
1630             goto Loverflow;

The dim(ension) of the static array is cast to an int and used.  So, any float
gets truncated and used.

Two issues:

1) add between 1623 and 1624:
dim = dim->checkIntegral();
That will result in an error like:
nocompile/o/opIndex_05.d:15:
'1.12799999999999999995402982788661461199808400124e+0' is not of integral type,
it is a double

2) that still doesn't fix the full bug, since what's also going on here is that
int[0] a is being allowed as well.  I didn't see anything in the language spec
that indicated this should be allowed and if so what the semantics are.

I tried the obvious fix, adding a d2 != 0 check, but that breaks
norun/a/assert_10_A.d (amongst others) where it passes a literal "" through a
char[] parameter, since it's a 0 length static array of chars.

More thinking required for part 2, and at 3am, I can't think. :)

Later,
Brad