[Issue 4444] Cannot index built-in array with expression tuple
http://d.puremagic.com/issues/show_bug.cgi?id= Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2011-07-18 23:35:30 PDT --- https://github.com/9rnsr/dmd/commit/0238f964842a736b87a6db1af4f60f6ef23ebdb1 https://github.com/D-Programming-Language/dmd/commit/f246e65e03c5e2102d92b176550e3fb28ef65d15 https://github.com/D-Programming-Language/dmd/commit/5b542c0332fd0ac803c7592b09c0d1bd9c2a512d -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5967] Mangling of ArgClose for variadic function is swapped
http://d.puremagic.com/issues/show_bug.cgi?id=5967 --- Comment #1 from kenn...@gmail.com 2011-07-19 02:07:01 PDT --- Doc fix: https://github.com/D-Programming-Language/d-programming-language.org/pull/17 Druntime is still _not_ fixed as https://github.com/D-Programming-Language/druntime/commit/a9e774dde6fe55d43d72f5206e04d462b51b0ebd has be reverted. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5956] Undocumented mangling of struct value
http://d.puremagic.com/issues/show_bug.cgi?id=5956 --- Comment #2 from kenn...@gmail.com 2011-07-19 02:09:49 PDT --- Doc fix: https://github.com/D-Programming-Language/d-programming-language.org/pull/17 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6346] Make == null a warning for arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6346 --- Comment #8 from Steven Schveighoffer schvei...@yahoo.com 2011-07-19 05:33:14 PDT --- Sorry for the duplicate comment, I wanted the first to be overwritten by the second (bugzilla told me that's what would happen), but it didn't :( Ignore comment 6 (/me wishes for comment editing/deleting) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6346] Make == null a warning for arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6346
--- Comment #6 from Steven Schveighoffer schvei...@yahoo.com 2011-07-19
05:31:19 PDT ---
(In reply to comment #5)
In pretty much every other language that I've ever used, null is _not_ the
same
thing as empty _ever_. Someone coming from C, C++, Java etc. is going to
expect
dynamic arrays to be able to be null. The way that you check for null in all
of
those languages is either == 0 or == null (or == NULL or == nullptr).
php just uses if(!arr) or if(arr == array()) or if(arr == null). All of those
return true for empty arrays.
But the point I was making is, for D null *is* synonymous with empty. D is not
every other language, and shouldn't be bound to the rules of those languages.
The larger question to answer here is, is it likely to be *wrong* when someone
enters:
if(arr == null)
and expects this to check if the pointer is null. The answer is very much no.
It's likely to be either *exactly* what you want, or harmless. The
super-subtle difference between null arrays and empty-but-not-null arrays is
seldom, if ever, used. Now, I agree that we could have a better built-in
moniker for is this array empty, but do we really need a warning? The code is
clear, unambiguous, and exactly what the developer wanted, or close enough to
be effective.
In java or C, checking an array for a null pointer is needed because an
unallocated array throws an exception or segfault if you try to use it. This
is not the case in D. D does not have this problem. Anyone's code who thinks
it does is bound to be obvious:
if(arr == null)
{
arr = new arr[5];
}
No need to warn here, the code is fine (works exactly how the user wants). But
the easy optimization is just to remove the if check.
is does
not exist in any other language that I've ever seen.
It exists in at least C# (Object.ReferenceEquals), php (===) and C has no need
for it, since operators can't be overloaded.
I fully expect programmers
from C, C++, Java etc. to expect == null to be checking whether an array is
null - that is whether is null is true. But it doesn't do that. It checks
whether length == 0.
Yeah, but the point I'm trying to make is, checking for an actual null pointer
means nothing in D! So checking if an array is empty is a much more useful
implementation. Null arrays are not bad things in D, they don't throw
exceptions or segfaults simply because they are null. If anything, the check
for null is probably extraneous, and can be removed.
But I really think that == null is a problem which is going
to throw off a lot of people. If I see it in code, I'm either going to point
it
out or change it (depending on the circumstances). The odds are just too high
that it doesn't do what the programmer intended or that someone else reading
the code will misinterpret what it does.
I completely disagree, the odds are very low that it's damaging or incorrect at
all. Experienced D coders use this feature all the time. You just gotta start
thinking in D instead of your previous languages.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6346] Make == null a warning for arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6346
--- Comment #7 from Steven Schveighoffer schvei...@yahoo.com 2011-07-19
05:32:02 PDT ---
(In reply to comment #5)
In pretty much every other language that I've ever used, null is _not_ the
same
thing as empty _ever_. Someone coming from C, C++, Java etc. is going to
expect
dynamic arrays to be able to be null. The way that you check for null in all
of
those languages is either == 0 or == null (or == NULL or == nullptr).
php just uses if(!arr) or if(arr == array()) or if(arr == null). All of those
return true for empty arrays.
But the point I was making is, for D null *is* synonymous with empty. D is not
every other language, and shouldn't be bound to the rules of those languages.
The larger question to answer here is, is it likely to be *wrong* when someone
enters:
if(arr == null)
and expects this to check if the pointer is null. The answer is very much no.
It's likely to be either *exactly* what you want, or harmless. The
super-subtle difference between null arrays and empty-but-not-null arrays is
seldom, if ever, used. Now, I agree that we could have a better built-in
moniker for is this array empty, but do we really need a warning? The code is
clear, unambiguous, and exactly what the developer wanted, or close enough to
be effective.
In java or C, checking an array for a null pointer is needed because an
unallocated array throws an exception or segfault if you try to use it. This
is not the case in D. D does not have this problem. Anyone's code who thinks
it does is bound to be obvious:
if(arr == null)
{
arr = new int[5];
}
No need to warn here, the code is fine (works exactly how the user wants). But
the easy optimization is just to remove the if check.
is does
not exist in any other language that I've ever seen.
It exists in at least C# (Object.ReferenceEquals), php (===) and C has no need
for it, since operators can't be overloaded.
I fully expect programmers
from C, C++, Java etc. to expect == null to be checking whether an array is
null - that is whether is null is true. But it doesn't do that. It checks
whether length == 0.
Yeah, but the point I'm trying to make is, checking for an actual null pointer
means nothing in D! So checking if an array is empty is a much more useful
implementation. Null arrays are not bad things in D, they don't throw
exceptions or segfaults simply because they are null. If anything, the check
for null is probably extraneous, and can be removed.
But I really think that == null is a problem which is going
to throw off a lot of people. If I see it in code, I'm either going to point
it
out or change it (depending on the circumstances). The odds are just too high
that it doesn't do what the programmer intended or that someone else reading
the code will misinterpret what it does.
I completely disagree, the odds are very low that it's damaging or incorrect at
all. Experienced D coders use this feature all the time. You just gotta start
thinking in D instead of your previous languages.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6194] [GSoC] Destructor gets called on object before it is copied when calling writeln()
http://d.puremagic.com/issues/show_bug.cgi?id=6194 --- Comment #4 from Cristi Cobzarenco cristi.cobzare...@gmail.com 2011-07-19 06:24:20 PDT --- Here's a pull request with my fix. https://github.com/D-Programming-Language/phobos/pull/151 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5667] [GSoC] clear does not call destructors on structs embedded in structs
http://d.puremagic.com/issues/show_bug.cgi?id=5667 --- Comment #5 from Cristi Cobzarenco cristi.cobzare...@gmail.com 2011-07-19 06:28:06 PDT --- *** Issue 6203 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6203] [GSoC] RefCounted (and clear()) doesn't call destructors of members of structs.
http://d.puremagic.com/issues/show_bug.cgi?id=6203 Cristi Cobzarenco cristi.cobzare...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Cristi Cobzarenco cristi.cobzare...@gmail.com 2011-07-19 06:28:06 PDT --- The cause is the same as in Issue 5667. *** This issue has been marked as a duplicate of issue 5667 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6347] New: dmd 2.054, gcc 4.2.3 - can not compile dmd from source
http://d.puremagic.com/issues/show_bug.cgi?id=6347 Summary: dmd 2.054, gcc 4.2.3 - can not compile dmd from source Product: D Version: D2 Platform: x86_64 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d...@metis.utfs.org --- Comment #0 from Alexander d...@metis.utfs.org 2011-07-19 08:45:11 PDT --- Created an attachment (id=1010) compiler output $ make -f linux.mak g++ -m64 idgen.c -o idgen [...] types.o ti_pvoid.o libelf.o elfobj.o -o dmd cast.o: In function `CastExp::getIntRange()': cast.c:(.text+0x541): undefined reference to `IntRange::cast(Type*)' cast.o: In function `IntegerExp::getIntRange()': cast.c:(.text+0x59a): undefined reference to `IntRange::cast(Type*)' cast.o: In function `MulExp::getIntRange()': cast.c:(.text+0x61e): undefined reference to `SignExtendedNumber::operator*(SignExtendedNumber const) const' cast.c:(.text+0x636): undefined reference to `SignExtendedNumber::operator*(SignExtendedNumber const) const' cast.c:(.text+0x650): undefined reference to `SignExtendedNumber::operator*(SignExtendedNumber const) const' cast.c:(.text+0x665): undefined reference to `SignExtendedNumber::operator*(SignExtendedNumber const) const' cast.c:(.text+0x67e): undefined reference to `IntRange::fromNumbers4(SignExtendedNumber const*)' [...] collect2: ld returned 1 exit status make: *** [dmd] Error 1 Note: I was able to compile dmd 2.053. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5816] clear breaks associative array
http://d.puremagic.com/issues/show_bug.cgi?id=5816 d...@dawgfoto.de changed: What|Removed |Added Status|NEW |RESOLVED CC||d...@dawgfoto.de Resolution||DUPLICATE --- Comment #1 from d...@dawgfoto.de 2011-07-19 09:21:33 PDT --- *** This issue has been marked as a duplicate of issue 5683 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5683] Calling .clear on a fresh associative array causes subsequent segfault
http://d.puremagic.com/issues/show_bug.cgi?id=5683 d...@dawgfoto.de changed: What|Removed |Added CC||ratchet.fr...@gmail.com --- Comment #2 from d...@dawgfoto.de 2011-07-19 09:21:33 PDT --- *** Issue 5816 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6347] Switch to posix.mak is not listed in changelog, and linux.mak is still in zip
http://d.puremagic.com/issues/show_bug.cgi?id=6347 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Platform|x86_64 |All Summary|dmd 2.054, gcc 4.2.3 - can |Switch to posix.mak is not |not compile dmd from source |listed in changelog, and ||linux.mak is still in zip --- Comment #1 from yebblies yebbl...@gmail.com 2011-07-20 02:54:57 EST --- Starting with 2.054, posix.mak should be used for building on linux, not linux.mak. This really should be in the changelog and linux.mak should be removed from the zip. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6346] Make == null a warning for arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6346 --- Comment #9 from Jonathan M Davis jmdavisp...@gmx.com 2011-07-19 11:21:49 PDT --- Except that null and empty are _not_ the same for arrays. True, checking for null is not as necessary in D, but you _can_ write code which relies on whether arrays are null or not. And the most likely thing that someone is going to do if they're writing code like that is to use == null, unless they were paying a lot of attention when reading the online docs or TDPL and remembered is and how it differs from ==. If == null and is null were identical, it wouldn't be an issue, but they're not. It can matter whether a function returns null or (or []). It can matter whether you use == or is. And I wouldn't expect many people new to D to correctly use is with null. Rather, if they're checking for null, they'll use == null. And since there is _zero_ need for == null given the alternatives and given how it's likely that a newbie would use == where they should use is, I see no reason that good D code should be using == null (at best, it's a bit prettier than length == 0, and given that empty matters with containers, empty should be encouraged over length == 0 anyway). So, given that it's going to cause problems (and bugs) for newbies, and anyone who knows what they're doing doesn't need it, I really think that there should be a warning for using == null. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6348] New: Returning a struct from a C library function doesn't work correctly in 64 bit binaries
http://d.puremagic.com/issues/show_bug.cgi?id=6348
Summary: Returning a struct from a C library function doesn't
work correctly in 64 bit binaries
Product: D
Version: D1 D2
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: siegelords_ab...@yahoo.com
--- Comment #0 from siegelords_ab...@yahoo.com 2011-07-19 11:52:32 PDT ---
Create two files with these contents.
File: test.c
typedef struct
{
float r,g,b,a;
} COLOR;
COLOR makecol(float r, float g, float b, float a)
{
COLOR ret;
ret.r = r;
ret.g = g;
ret.b = b;
ret.a = a;
return ret;
}
File: test.d
import std.stdio;
struct COLOR
{
float r,g,b,a;
}
extern (C) COLOR makecol(float r, float g, float b, float a);
void main()
{
auto col = makecol(1, 0.5, 1, 0.5);
writefln(%s, %s, %s, %s, col.r, col.g, col.b, col.a);
}
Now compile the whole mess and test:
gcc -c test.c ar -r test.a test.o
dmd test.d test.a
./test
The expected output is 1, 0.5, 1, 0.5 but actually it output something
completely different (0, 0, 0, 0 on my system). This happens with both dmd
2.054 and 1.069.
Perhaps this bug is related to 5570?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 5683] Calling .clear on a fresh associative array causes subsequent segfault
http://d.puremagic.com/issues/show_bug.cgi?id=5683
d...@dawgfoto.de changed:
What|Removed |Added
CC||d...@dawgfoto.de
--- Comment #3 from d...@dawgfoto.de 2011-07-19 12:54:13 PDT ---
A quickfix if urgently needed by anybody is to add a static init method to the
template AA structure.
struct AssociativeArray(Key, Value)
{
static Value[Key] init() @property
{
void* p;
return *cast(Value[Key]*)(p);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6349] New: HTOD needs -od or -of switch
http://d.puremagic.com/issues/show_bug.cgi?id=6349 Summary: HTOD needs -od or -of switch Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: critical Priority: P2 Component: htod AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2011-07-19 16:28:17 PDT --- I can't use my build script for the DWindowsProject to generate headers because it's multithreaded and HTOD works by outputting any converted .h header file to the *current directory*, e.g.: htod foo\bar.h This puts the bar.d file to the *current directory*. I can't just move this newly generated .d header around because my builder is multithreaded and what ends up happening is multiple translated header files with the same name get overwritten with each other. I need -od or -of for HTOD, just like we have in DMD. I can't use an explicit name because: htod foo\bar.h foo\bar.d Here's what bar.d has in its contents: /* Converted to D from foo\bar.h by htod */ module foo\bar; That won't compile. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6350] New: Const array static usage optimization
http://d.puremagic.com/issues/show_bug.cgi?id=6350
Summary: Const array static usage optimization
Product: D
Version: unspecified
Platform: All
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2011-07-19 16:58:20 PDT ---
A D2 program:
enum int[1] array1 = [10];
int foo(int[1] v) {
return array1[0] * v[0];
}
const int[1] array2 = [10];
int bar(int[1] v) {
return array2[0] * v[0];
}
void main() {}
The asm of the two functions (dmd 2.054, -O -release), inside bar() the
contents of array2 are loaded with a mov instruction:
_D4test3fooFG1iZi comdat
pushEAX
lea EAX,[EAX*4][EAX]
add EAX,EAX
pop ECX
ret
_D4test3barFG1iZi comdat
pushEAX
mov EAX,_D4test6array2xG1i
imulEAX,[ESP]
pop ECX
ret
Is it possible for the compiler for such common case of const array to remove
the mov instruction from the bar () function too?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6351] New: Regression(2.054) Segfault: Vararg delegate as template param
http://d.puremagic.com/issues/show_bug.cgi?id=6351
Summary: Regression(2.054) Segfault: Vararg delegate as
template param
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: cbkbbej...@mailinator.com
--- Comment #0 from Nick Sabalausky cbkbbej...@mailinator.com 2011-07-19
20:01:57 PDT ---
This crashes the compiler:
void foo(alias dg)()
{
dg();
}
alias foo!( (int[] a...){} ) bar;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6352] New: Regression(2.054) Implicit pure/nothrow/@safe messes up delegate arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6352
Summary: Regression(2.054) Implicit pure/nothrow/@safe messes
up delegate arrays
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: cbkbbej...@mailinator.com
--- Comment #0 from Nick Sabalausky cbkbbej...@mailinator.com 2011-07-19
21:00:27 PDT ---
pure:
-
int a;
void main()
{
void delegate()[] dgArray = [
() {},
() { a = 1; }
];
}
-
testDgArray1.d(7): Error: incompatible types for ((__dgliteral1) ?
(__dgliteral2)): 'void delegate() pure nothrow @safe' and 'void delegate()
nothrow @safe'
==
nothrow:
-
void main()
{
void delegate()[] dgArray = [
() {},
() { throw new Exception(); }
];
}
-
testDgArray2.d(6): Error: incompatible types for ((__dgliteral1) ?
(__dgliteral2)): 'void delegate() pure nothrow @safe' and 'void delegate() pure
@safe'
==
@safe:
-
void main()
{
void delegate()[] dgArray = [
() {},
() { *(cast(int*)0) = 1; }
];
}
-
testDgArray3.d(6): Error: incompatible types for ((__dgliteral1) ?
(__dgliteral2)): 'void delegate() pure nothrow @safe' and 'void delegate() pure
nothrow @system'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6352] Regression(2.054) Implicit pure/nothrow/@safe messes up delegate arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6352 Nick Sabalausky cbkbbej...@mailinator.com changed: What|Removed |Added Severity|normal |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6352] Regression(2.054) Implicit pure/nothrow/@safe messes up delegate arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6352 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2011-07-20 14:25:43 EST --- This is essentially issue 3180, but the regression part is of course new. Maybe 3180 should be elevated to regression? I'm not really sure. I have a patch for this, but I'm waiting for my fix to issue 3797 to be applied first. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6352] Regression(2.054) Implicit pure/nothrow/@safe messes up delegate arrays
http://d.puremagic.com/issues/show_bug.cgi?id=6352 Nick Sabalausky cbkbbej...@mailinator.com changed: What|Removed |Added Depends on||3180 --- Comment #2 from Nick Sabalausky cbkbbej...@mailinator.com 2011-07-19 21:30:20 PDT --- I'll mark this as depending on issue 3180. That should be good enough. Other parts of 3180 aren't regressions, after all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
