[Issue 5694] New: va_arg doesn't work with idouble and ifloat

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5694

   Summary: va_arg doesn't work with idouble and ifloat
   Product: D
   Version: unspecified
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: mathias.baum...@sociomantic.com


--- Comment #0 from Mathias Baumann mathias.baum...@sociomantic.com 
2011-03-04 05:05:08 PST ---
Created an attachment (id=927)
test case showing the problem

In 64bit va_arg does not give back the correct pointer for the type idouble and
ifloat. I haven't tested more types so far, but I guess cfloat and cdouble will
give problems, too

see attached test case. In 32bit the outputs are the same, in 64bit not.

I only tested this on D1, but I assume it will have the same problems on D2

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


[Issue 5695] New: Problem with TypeTuple of lambdas

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5695

   Summary: Problem with TypeTuple of lambdas
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: wrong-code
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2011-03-04 05:11:10 PST ---
I don't understand what's happening here, but there is a problem somewhere
(maybe in this code), D2 code:


import std.stdio, std.typetuple;

alias TypeTuple!((double x){ return x + x; },
 (double x){ return x * x; }) funcs1;

double foo1(double x) { return x + x; }
double foo2(double x) { return x * x; }
alias TypeTuple!(foo1, foo2) funcs2;

void main() {
enum double x = 5.0;

foreach (f; funcs1)
writeln(f(x));

foreach (f; funcs2)
writeln(f(x));
}


It prints (DMD 2.052):
5.28268e-308
0
10
25

Instead of:
10
25
10
25

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


[Issue 5694] va_arg doesn't work with idouble and ifloat

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5694


Mathias Baumann mathias.baum...@sociomantic.com changed:

   What|Removed |Added

 Attachment #927 is|0   |1
   obsolete||


--- Comment #1 from Mathias Baumann mathias.baum...@sociomantic.com 
2011-03-04 05:17:50 PST ---
Created an attachment (id=928)
testcase for ifloat, idouble, cdouble, cfloat

I extended the testcase to cfloat and cdouble.

It works with cdouble. and it gives 

   Internal error: backend/cgcod.c 576

with cfloat, so I couldn't test that part.

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


[Issue 5691] walkLength() compatible with opApply()

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5691


Steven Schveighoffer schvei...@yahoo.com changed:

   What|Removed |Added

 CC||schvei...@yahoo.com


--- Comment #10 from Steven Schveighoffer schvei...@yahoo.com 2011-03-04 
05:44:27 PST ---
Couldn't walkLength simply be redefined to accept an isIterable argument?  That
covers ranges, opApply, and properly formed delegates.

And to answer Jonathan, opApply has very important features that ranges do not.
 First and foremost, it can use the stack for iteration.  This allows things
like indexed iteration, iterating trees, and efficient iterating via a virtual
interface.

Second, ranges do not yet allow more than one item while iterating.  I can't
do:

foreach(i, x; r)

on a range.

Not saying opApply is better in all cases, ranges do have just as important
features, but opApply is more useful in certain important situations.

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


[Issue 5691] walkLength() compatible with opApply()

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5691



--- Comment #12 from Steven Schveighoffer schvei...@yahoo.com 2011-03-04 
08:13:08 PST ---
I agree that we don't want to cater to all styles, at the expense of added
complexity.  I think actually, using isIterable, does not increase complexity
immensely for walkLength.  It covers the same ground as isInputRange, but with
the added bonus of allowing any foreachable structure.

One thing to note is, you cannot convert opApply (or similar) constructs into
ranges.  This means that any function/construct in std.algorithm or std.range
that yields a range cannot be used on a generic isIterable type.  For example,
map yields a range, so it cannot accept opApply type arguments.

In addition, any function which operates on multiple aggregates could not take
opApply-based args because you can't iterate them in parallel easily.  This
eliminates quite a few functions.

However, any functions that operate on the *whole* set of values from a range
should be easily tweaked to also accept isIterable.

For example, reduce, some forms of count, isSorted, etc. should be possible on
any foreachable construct.

I think we may find that a) the number of functions which can also accept
isIterable types is pretty small and b) adding the ability to support
opApply-based aggregates is not complex.

It definitely needs more analysis before judging whether it makes sense.  I
agree that if you do walkLength, you should do all the functions that make
sense.

BTW, I just noticed that count(r) is identical to walkLength(r).  Any reason
for the duplication?

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


[Issue 5691] walkLength() compatible with opApply()

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5691



--- Comment #13 from Andrei Alexandrescu and...@metalanguage.com 2011-03-04 
08:35:41 PST ---
walkLength would need forking for opApply, so already for this first example
we're looking at an increase in complexity. This is because walkLength against
a range doesn't need to invoke front, so it uses a straight for loop.

The difference between walkLength and count is that walkLength accepts a limit.

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


[Issue 5696] New: Templates typetuple iteration

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5696

   Summary: Templates typetuple iteration
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2011-03-04 09:48:45 PST ---
I am allowed to create a type tuple of function templates, but then it seems I
am not allowed to use a static foreach on that type tuple:


template TypeTuple(TList...) {
alias TList TypeTuple;
}
int foo(T)(T x) {
return 0;
}
void main() {
alias TypeTuple!(foo, foo) t2;
static assert(t2[0](0) == 0); // OK
static assert(t2[1](0) == 0); // OK
foreach (t; t2) {} // Error
}


DMD 2.052 shows:

test.d(11): Error: variable test.main.t voids have no value
test.d(11): Error: template foo(T) has no value
test.d(11): Error: variable test.main.t voids have no value
test.d(11): Error: template foo(T) has no value

See also bug 2411

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


[Issue 5697] New: Instantiation from typetuple of templates

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5697

   Summary: Instantiation from typetuple of templates
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2011-03-04 09:50:53 PST ---
This D2 code compiles and runs with no errors (DMD 2.052):


template TypeTuple(TList...) {
alias TList TypeTuple;
}
int foo(alias bar)() {
return bar();
}
int spam() {
return 1;
}
void main() {
alias TypeTuple!(foo, foo) templates;
alias templates[0] templates0; // OK
assert(templates0!spam() == 1); // OK
}




But if I remove the alias, to merge the last two lines:

template TypeTuple(TList...) {
alias TList TypeTuple;
}
int foo(alias bar)() {
return bar();
}
int spam() {
return 1;
}
void main() {
alias TypeTuple!(foo, foo) templates;
assert(templates[0]!spam() == 1); // line 12, error
}



It doesn't compile, with the errors:

test.d(12): found '!' when expecting ')'
test.d(12): found 'spam' when expecting ';' following statement
test.d(12): expression expected, not ')'


Some alternative ways to write this line don't seem to work:
templates[0]!spam()

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


[Issue 5698] New: va_arg sets wrong length for (u)short[]

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5698

   Summary: va_arg sets wrong length for (u)short[]
   Product: D
   Version: unspecified
  Platform: x86_64
OS/Version: Linux
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: mathias.baum...@sociomantic.com


--- Comment #0 from Mathias Baumann mathias.baum...@sociomantic.com 
2011-03-04 10:07:48 PST ---
Created an attachment (id=929)
test case demonstrating the problem

va_arg sets wrong length for ushort[]

the attached program outputs: 

vararg_:
ubyte[].length = 3
ushort[].length = 140737237065760
short[].length = 139885158469104
uint[].length = 3
vararg:
ubyte[].length = 3
ushort[].length = 0
short[].length = 0
uint[].length = 3


I tested with D1, but the bug is possibly also existant in D2.

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


[Issue 5699] New: opBinary used to implement in in TotalContainer

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5699

   Summary: opBinary used to implement in in TotalContainer
   Product: D
   Version: D2
  Platform: Other
OS/Version: Mac OS X
Status: NEW
  Severity: normal
  Priority: P2
 Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: mag...@hetland.org


--- Comment #0 from Magnus Lie Hetland mag...@hetland.org 2011-03-04 10:37:53 
PST ---
The TotalContainer example class uses opBinary to implement the in operator,
while it should use opBinaryRight.

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


[Issue 5699] opBinary used to implement in in TotalContainer

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5699


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2011-03-04 11:23:15 
PST ---
Please be more specific. Where is this example?

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


[Issue 5699] opBinary used to implement in in TotalContainer

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5699


Steven Schveighoffer schvei...@yahoo.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||schvei...@yahoo.com
 Resolution||INVALID


--- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2011-03-04 
11:33:53 PST ---
I think it was on the example container for std.container that now is simply a
table.  I think this bug is obsolete.

See http://www.digitalmars.com/d/2.0/phobos/std_container.html

There is no longer a TotalContainer object.

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


[Issue 5569] 64 bit Dwarf symbolic debug info not recognized by gdb

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5569



--- Comment #3 from Mathias Baumann mathias.baum...@sociomantic.com 
2011-03-04 11:51:22 PST ---
I don't know whether it's related or not, but the linux libc function
backtrace only manages to extract one frame.

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


[Issue 5699] opBinary used to implement in in TotalContainer

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5699


Magnus Lie Hetland mag...@hetland.org changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|INVALID |


--- Comment #3 from Magnus Lie Hetland mag...@hetland.org 2011-03-04 11:58:09 
PST ---
I was referring to the TotalContainer class in std.container; you'll find it in
the repo, here:

https://github.com/D-Programming-Language/phobos/blob/master/std/container.d

The bug is still there.

The docs say, The following documentation and type $(D TotalContainer) are
intended for developers only, which might explain why it's not in the public
docs -- it's a no-op dummy container, after all (an example to use as a
starting-point). Still, if it is to serve as an example for developers, it
should be correct.

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


[Issue 5699] opBinary used to implement in in TotalContainer

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5699



--- Comment #4 from Steven Schveighoffer schvei...@yahoo.com 2011-03-04 
12:07:18 PST ---
Oh, my mistake!  The original docs did show the container in the documentation,
which is why I thought it was removed.

The exact location is here:

https://github.com/D-Programming-Language/phobos/blob/31d47df17fc77a5a16e4e51267eaa6952ba01213/std/container.d#L480

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


[Issue 5699] opBinary used to implement in in TotalContainer

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5699


Andrei Alexandrescu and...@metalanguage.com changed:

   What|Removed |Added

 Status|REOPENED|ASSIGNED
 CC||and...@metalanguage.com
 AssignedTo|nob...@puremagic.com|and...@metalanguage.com


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


[Issue 5700] New: Allow dup in nothrow functions

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5700

   Summary: Allow dup in nothrow functions
   Product: D
   Version: D2
  Platform: x86
OS/Version: Windows
Status: NEW
  Keywords: rejects-valid
  Severity: normal
  Priority: P2
 Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc


--- Comment #0 from bearophile_h...@eml.cc 2011-03-04 15:09:52 PST ---
In DMD 2.052 it's allowed to create a new dynamic array inside nothrow
functions, this compiles and works:


nothrow void foo(int[] a) {
auto b = new int[a.length];
b[] = a[];
}
void main() {}


But this almost equivalent code isn't accepted:


nothrow void foo(int[] a) {
a.dup;
}
void main() {}


DMD 2.052 shows:
test.d(2): Error: _adDupT is not nothrow
test.d(1): Error: function test.foo 'foo' is nothrow yet may throw

I suggest to let it accept the dup inside nothrow functions too.

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


[Issue 5701] New: Broken ddoc build using core.bitop.bswap

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5701

   Summary: Broken ddoc build using core.bitop.bswap
   Product: D
   Version: D2
  Platform: x86_64
OS/Version: Windows
Status: NEW
  Severity: regression
  Priority: P2
 Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: re...@netmail.co.nz


--- Comment #0 from Regan Heath re...@netmail.co.nz 2011-03-04 15:18:49 PST 
---
Using dmd v2.052 and link.exe 8.00.10

module main;

import core.bitop;

void main(string[] argv)
{
int a = 5;
a = bswap(a);
}

dmd -D ddoc_bitop_bug.d

OPTLINK (R) for Win32  Release 8.00.10
Copyright (C) Digital Mars 1989-2010  All rights reserved.
http://www.digitalmars.com/ctg/optlink.html
ddoc_bitop_bug.obj(ddoc_bitop_bug)
 Error 42: Symbol Undefined _D4core5bitop5bswapFkZk
--- errorlevel 1

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


[Issue 5700] Allow dup in nothrow functions

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5700



--- Comment #2 from bearophile_h...@eml.cc 2011-03-04 16:11:05 PST ---
I see, thank you for your comment. Then dup has to be conditionally nothrow,
and we go back to issue 5125. (There is no need for dup to be a template, the
conditional nothrow may work on normal functions too, I think).

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


[Issue 5125] Optional function purity/nothrowness

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5125


Jonathan M Davis jmdavisp...@gmx.com changed:

   What|Removed |Added

 CC||jmdavisp...@gmx.com


--- Comment #3 from Jonathan M Davis jmdavisp...@gmx.com 2011-03-04 16:44:23 
PST ---
I believe that Andrei's suggestion for pure was to add optional constraints to
pure. So, you'd have pure(condition) instead of pure, and the function would be
pure if the constraint was true. Presumably, we could do the same for nothrow
as well. @safe, @trusted, and @system (or at least @safe and @trusted) are in
the same boat. So, maybe it should just be generalized to all function
attributes (which would then presumably include stuff like public and private,
though that's pretty pointless other than avoiding special casing attributes
might be nice).

Regardless, we're going to need a solution for this if we want attributes like
pure to really work with templated functions.

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


[Issue 5694] va_arg doesn't work with idouble and ifloat

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5694


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 CC||bugzi...@digitalmars.com
Version|unspecified |D1  D2


--- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-03-04 
20:18:20 PST ---
First fix (not the internal error):

https://github.com/D-Programming-Language/druntime/commit/bd7b90f1c5dc681d05e872814379b709c1894d75

https://github.com/D-Programming-Language/phobos/commit/2830024ec775485cef643eec4d807dc7c1174d9d

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


[Issue 5694] va_arg doesn't work with idouble and ifloat

2011-03-04 Thread d-bugmail
http://d.puremagic.com/issues/show_bug.cgi?id=5694


Walter Bright bugzi...@digitalmars.com changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED


--- Comment #3 from Walter Bright bugzi...@digitalmars.com 2011-03-04 
23:13:08 PST ---
https://github.com/D-Programming-Language/dmd/commit/1ccf5b1e25793e5178643f35e5c16bc2194b566e

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

Fix for internal error.

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