Re: [Issue 3280] comparing array length is wonky

2009-09-01 Thread Ellery Newcomer
d-bugm...@puremagic.com wrote:
> See bug 259.
> 

Oh, gosh. I need multiple votes.


[Issue 3277] DMD includes a version of OleAut32.lib which is missing some functions

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3277


Stewart Gordon  changed:

   What|Removed |Added

 CC||s...@iname.com




--- Comment #1 from Stewart Gordon   2009-09-01 18:27:31 PDT ---
Since when has it been just that one .lib that's out of date?

(See also issue 317 comment 1.)

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


[Issue 3280] comparing array length is wonky

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3280


Jarrett Billingsley  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC||jarrett.billings...@gmail.c
   ||om




--- Comment #1 from Jarrett Billingsley   
2009-09-01 17:09:24 PDT ---
Sorry, invalid. typeof(s.length) is unsigned, typeof(-1) is signed. The
compiler should throw an error on the last assert, but doesn't. Instead, it
casts -1 to size_t, resulting in something like "assert(s.length >
0x);" See bug 259.

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


[Issue 3280] comparing array length is wonky

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3280


Jarrett Billingsley  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution||INVALID




--- Comment #2 from Jarrett Billingsley   
2009-09-01 17:09:39 PDT ---
Oops

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


[Issue 3280] New: comparing array length is wonky

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3280

   Summary: comparing array length is wonky
   Product: D
   Version: 2.031
  Platform: Other
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ellery-newco...@utulsa.edu


void main(){
string s;
int a = s.length;
assert(a == 0);
assert(s.length == 0);
assert(a == 0);
assert(a > -1);
assert(s.length > -1); //fails
}

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


[Issue 3279] New: Type tuple comparison fails

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3279

   Summary: Type tuple comparison fails
   Product: D
   Version: 2.032
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: blocker
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bart...@relisoft.com


I get this strange error message:

Error: incompatible types for (((long, int)) == ((long, int))): '(long, int)'
and '(long, int)'

when compiling this program:

import std.typetuple;

template TypeList(T...)
{
alias T toTuple;
}

template snoC(T, alias List)
{
alias TypeList!(List.toTuple, T) snoC;
}

static assert (snoC!(int, TypeList!(long)).toTuple == TypeTuple!(long, int));


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


[Issue 3278] New: Empty tuples don't match

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3278

   Summary: Empty tuples don't match
   Product: D
   Version: 2.032
  Platform: Other
OS/Version: Windows
Status: NEW
  Severity: critical
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bart...@relisoft.com


A tuple containing an empty tuple is not the same as an empty tuple and two
such beasts are considered incompatible.

import std.typetuple;

template TypeList(T...)
{
alias T toTuple;
}

static assert (TypeList!().toTuple == TypeTuple!());

Error: incompatible types for ((()) == (())): '()' and '()'

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


[Issue 1253] array initializers as expressions are not allowed in const arrays

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1253


Don  changed:

   What|Removed |Added

   Keywords||patch




--- Comment #6 from Don   2009-09-01 08:24:13 PDT ---
And here's a patch.
Cause: The initializer is used in declaration.c, VarDeclaration::semantic().
We see the lines:
--
Expression *e = init->toExpression();
if (!e)
{
init = init->semantic(sc, type);
e = init->toExpression();
if (!e)
--
The initializer is supposed to return NULL if the initializer semantic hasn't
been run yet. But the array initializer doesn't -- it prints an error, and
returns an ErrorExp instead! It never has a chance.

PATCH: init.c, last lines of ArrayInitializer::toExpression() (around line
473).

Lno:
delete elements;
-   error(loc, "array initializers as expressions are not allowed");
-   return new ErrorExp();
+return NULL;
}

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


[Issue 1253] array initializers as expressions are not allowed in const arrays

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1253


Don  changed:

   What|Removed |Added

 CC||clugd...@yahoo.com.au
Version|0.175   |2.022
Summary|DMD 0.175 introduced bug:   |array initializers as
   |array initializers as   |expressions are not allowed
   |expressions are not |in const arrays
   |allowed?|
   Severity|regression  |normal




--- Comment #5 from Don   2009-09-01 07:33:56 PDT ---
This works for me on D1.046. It was fixed somewhere between 1.020 and 1.041.

It also works on DMD2.031, if you change 'const' to 'enum' to preserve the
semantics.

Oddly, however, on DMD2.031 the code as-written still displays:

bug.d(173): Error: array initializers as expressions are not allowed

So this is now a D2-only bug, which is not a regression. It's never worked with
these semantics. Checked as far back as 2.022.

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


[Issue 3173] ICE(mtype.c) on wrong code (double to long to int conversion)

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3173





--- Comment #3 from Don   2009-09-01 04:25:11 PDT ---
Patch was incomplete, fails for the test case below. Need to also add this code
to the end of CastExp::getIntRange()

+   if (type->isintegral()) {
ir.imin &= type->sizemask();
ir.imax &= type->sizemask();
+}
   return ir;
}


Test case:

  ubyte b = 6;
  short c5 = cast(int)(b + 6.1);

This is arguably an ice-on-valid-code.

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


[Issue 3277] New: DMD includes a version of OleAut32.lib which is missing some functions

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3277

   Summary: DMD includes a version of OleAut32.lib which is
missing some functions
   Product: D
   Version: 1.046
  Platform: x86
OS/Version: Windows
Status: NEW
  Severity: normal
  Priority: P3
 Component: installer
AssignedTo: bugzi...@digitalmars.com
ReportedBy: we...@beardmouse.org.uk


As mentioned in the thread @
http://www.dsource.org/forums/viewtopic.php?t=4747, DMD includes a version of
OleAut32.lib which is missing some functions.

Would it be possible to update it to a newer version?

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


[Issue 1382] memory allocated for arrays in CTFE functions during compilation is not released

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=1382


Don  changed:

   What|Removed |Added

   Severity|blocker |critical




--- Comment #5 from Don   2009-08-31 23:59:27 PDT ---
Reducing severity back to critical, since the voting system takes care of the
importance.

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


[Issue 3173] ICE(mtype.c) on wrong code (double to long to int conversion)

2009-09-01 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=3173


Don  changed:

   What|Removed |Added

   Keywords||patch
 OS/Version|Linux   |All




--- Comment #2 from Don   2009-08-31 23:56:38 PDT ---

Cause: default case for getIntRange() assumes it's an integer, which isn't true
if there's casting.
Solution: if not an integer, assume it could contain anything.

PATCH: cast.c, line 1902 (in Walter's private beta of DMD2.032):

IntRange Expression::getIntRange()
{
IntRange ir;
ir.imin = 0;
if (type->isintegral())
ir.imax = type->sizemask();
else
ir.imax = 0xULL; // assume the worst
return ir;
}

===
TEST CASES FOR TEST SUITE
===

struct S3173{
   double z;
}

int bug3173(int x) {  return x; }

S3173 s3173;
double e3173 = 4;
const double d3173 = 4;
// invalid, but should not ICE

static assert(!is(typeof(bug3173(cast(long)e3173;
static assert(!is(typeof(bug3173(cast(long)s3173;
static assert(!is(typeof(bug3173(cast(long)3.256679e30;
// And two valid cases:
static assert(is(typeof(bug3173(cast(long)d3173;
static assert(is(typeof(bug3173(cast(long)3.256679e4;

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