[Issue 4231] Solitary opUnary Postincrement and Postdecrement user defined operators are broken.
http://d.puremagic.com/issues/show_bug.cgi?id=4231
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #10 from Don clugd...@yahoo.com.au 2010-06-08 00:01:20 PDT ---
This patch only stops the side effect message, it doesn't turn x++; into ++x;
Note that this patch deals with more difficult cases such as:
struct Foo{
int opUnary(string op)() { return 1; }
}
void main() {
Foo foo;
int w;
++w, foo++;
}
Index: expression.c
===
--- expression.c(revision 526)
+++ expression.c(working copy)
@@ -8520,6 +8520,14 @@
int CommaExp::checkSideEffect(int flag)
{
+// Check for compiler-generated code of the form auto __tmp, e, __tmp;
+// In such cases, only check e for side effect (it's OK for __tmp to have
no side effect).
+CommaExp * firstComma = this;
+while (firstComma-e1-op == TOKcomma)
+firstComma = (CommaExp *)firstComma-e1;
+if (firstComma-e1-op == TOKdeclaration e2-op == TOKvar)
+return e1-checkSideEffect(flag);
+
if (flag == 2)
return e1-checkSideEffect(2) || e2-checkSideEffect(2);
else
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4231] Solitary opUnary Postincrement and Postdecrement user defined operators are broken.
http://d.puremagic.com/issues/show_bug.cgi?id=4231 --- Comment #11 from Brad Roberts bra...@puremagic.com 2010-06-08 00:24:37 PDT --- Hrm.. I haven't studied the side effect code enough. Do you know why Comma:Exp::checkSideEffect isn't just: return e1-checkSideEffect(flag) || e2-checkSideEffect(flag) ie, no conditional. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4231] Solitary opUnary Postincrement and Postdecrement user defined operators are broken.
http://d.puremagic.com/issues/show_bug.cgi?id=4231
--- Comment #12 from Don clugd...@yahoo.com.au 2010-06-08 01:22:02 PDT ---
(In reply to comment #11)
Hrm.. I haven't studied the side effect code enough. Do you know why
Comma:Exp::checkSideEffect isn't just:
return e1-checkSideEffect(flag) || e2-checkSideEffect(flag)
ie, no conditional.
If flag isn't 2, you still want to check for a useless subexpression.
Eg.
int x;
int y;
++y, x;
This should still be an error, since x; has no effect.
This shows me that my patch isn't quite right, it will erroneously allow
void main() {
Foo foo;
int w;
foo++, w;
}
--
Revised patch (added one line): should ensure that the created variable is the
same as the one which is returned.
CommaExp * firstComma = this;
while (firstComma-e1-op == TOKcomma)
firstComma = (CommaExp *)firstComma-e1;
if (firstComma-e1-op == TOKdeclaration e2-op == TOKvar
+ ((DeclarationExp *)firstComma-e1)-declaration ==
((VarExp*)e2)-var)
return e1-checkSideEffect(flag);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4231] Solitary opUnary Postincrement and Postdecrement user defined operators are broken.
http://d.puremagic.com/issues/show_bug.cgi?id=4231 --- Comment #13 from Brad Roberts bra...@puremagic.com 2010-06-08 02:07:14 PDT --- Something about that code bugs me, but I'm having trouble deciding exactly what it is. Part of it is that there's redundant work. Move the new code inside the else block? Part of it is also that it presumes a good bit about the structure of the tree inside a comma expression. The comment suggests that it can only come from generated code w/in the compiler. How true is that? How future proof is it? Anyway, maybe my subconscious will figure out what's really bugging me while I sleep. More tomorrow... if anything comes to me. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3690] Folding Complex!(Complex!T) to Complex!T
http://d.puremagic.com/issues/show_bug.cgi?id=3690 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-06-08 02:36:42 PDT --- Implemented in the new std.complex, included since DMD 2.044. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4293] Wrong line number with @disable
http://d.puremagic.com/issues/show_bug.cgi?id=4293 --- Comment #2 from Jason House jason.james.ho...@gmail.com 2010-06-08 03:31:12 PDT --- My goal with doing this was to catch uses of the default constructor because in the original use case, it was always a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4294] New: Importing std.typecons in two modules while unittesting breaks program
http://d.puremagic.com/issues/show_bug.cgi?id=4294 Summary: Importing std.typecons in two modules while unittesting breaks program Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: simen.kja...@gmail.com --- Comment #0 from Simen Kjaeraas simen.kja...@gmail.com 2010-06-08 03:39:07 PDT --- // module a; import std.typecons; alias Tuple!( float ) foo; // module b; import std.typecons; // Compiling with dmd a b -unittest gives the following output: E:\DMD\DMD2\windows\bin\..\..\src\phobos\std\typecons.d(424): Error: static assert (is(Tuple!(string,float) == Tuple!(string,float))) is false E:\DMD\DMD2\windows\bin\..\..\src\phobos\std\typecons.d(413): instantiated from here: Tuple!(string,float) E:\DMD\DMD2\windows\bin\..\..\src\phobos\std\typecons.d(423): instantiated from here: slice!(1,3) E:\DMD\DMD2\windows\bin\..\..\src\phobos\std\typecons.d(420): instantiated from here: Tuple!(int,string,float,double) a.d(3):instantiated from here: Tuple!(float) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4294] Importing std.typecons in two modules while unittesting breaks program
http://d.puremagic.com/issues/show_bug.cgi?id=4294 --- Comment #1 from Simen Kjaeraas simen.kja...@gmail.com 2010-06-08 03:57:39 PDT --- Allow me to rectify a mistake in the original post. dmd a b -unittest compiles with no problems. dmd b a -unittest is what causes the posted bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4231] Solitary opUnary Postincrement and Postdecrement user defined operators are broken.
http://d.puremagic.com/issues/show_bug.cgi?id=4231 --- Comment #14 from Don clugd...@yahoo.com.au 2010-06-08 04:13:39 PDT --- (In reply to comment #13) Something about that code bugs me, but I'm having trouble deciding exactly what it is. Part of it is that there's redundant work. Move the new code inside the else block? Although the code in the else block is the same, it's for a very different reason. But I'm not sure it's correct. For example, int x; x, ++x; doesn't raise an error. Yet the first x has no effect! Shouldn't the part in the else clause be e1-sideeffect() e2-sideeffect() ? Part of it is also that it presumes a good bit about the structure of the tree inside a comma expression. The comment suggests that it can only come from generated code w/in the compiler. How true is that? How future proof is it? Declarations are not legal inside comma expressions. But the compiler generates them in several places. They are also used in implementing struct constructors and postblit, for example. There's definitely something a bit weird about the compiler generating code that couldn't get past the parsing stage. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4294] Importing std.typecons in two modules while unittesting breaks program
http://d.puremagic.com/issues/show_bug.cgi?id=4294 Simen Kjaeraas simen.kja...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Simen Kjaeraas simen.kja...@gmail.com 2010-06-08 06:41:43 PDT --- *** This issue has been marked as a duplicate of issue 4003 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4003] The result changes only with the order of source files.
http://d.puremagic.com/issues/show_bug.cgi?id=4003 Simen Kjaeraas simen.kja...@gmail.com changed: What|Removed |Added CC||simen.kja...@gmail.com --- Comment #1 from Simen Kjaeraas simen.kja...@gmail.com 2010-06-08 06:41:43 PDT --- *** Issue 4294 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 3923] std.algorithm.find is too much hard to understand
http://d.puremagic.com/issues/show_bug.cgi?id=3923 Bill Baxter wbax...@gmail.com changed: What|Removed |Added CC||wbax...@gmail.com --- Comment #1 from Bill Baxter wbax...@gmail.com 2010-06-08 06:56:07 PDT --- (In reply to comment #0) If you need more than 10 minutes to understand how to use something as simple as a find, then the library API is badly designed. It's not a limit of my brain, it's a problem in the library design. Or else it's a problem in its documentation. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4003] The result changes only with the order of source files.
http://d.puremagic.com/issues/show_bug.cgi?id=4003 Lars T. Kyllingstad bugzi...@kyllingen.net changed: What|Removed |Added CC||bugzi...@kyllingen.net Severity|normal |major --- Comment #2 from Lars T. Kyllingstad bugzi...@kyllingen.net 2010-06-08 07:03:47 PDT --- I'm raising the importance of this. Every time your program uses two Phobos modules that both import std.typecons, you risk running into this bug. See bug 4294 for a marginally more narrow test case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3923] std.algorithm.find is too much hard to understand
http://d.puremagic.com/issues/show_bug.cgi?id=3923 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer schvei...@yahoo.com 2010-06-08 07:44:28 PDT --- This is typical of STL documentation too. The issue is that because of the power of templates, you can pack an amazing amount of usages into one function, and IFTI makes it resolve to the simplest form. What I would advise is to read the examples, not the signature. Most of the time, you do not need the full power of find's features. In particular, calling the second argument needles, and calling the type Ranges makes it difficult to understand you can simply just pass a single value to get what you want. But the examples are easy to understand. Maybe a message at the top of the std.algorithm page to recommend reading the examples if you don't understand the signatures. One thing that Tango does to help in this regard is to have a version(ddoc) for complex signatures so one can fine-tune how the signature looks in ddoc. Maybe an enhancement for ddoc would be to be able to specify a simple signature form, then you could click on a link to have it expand to the full signature. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3923] std.algorithm.find is too much hard to understand
http://d.puremagic.com/issues/show_bug.cgi?id=3923 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added CC||and...@metalanguage.com --- Comment #3 from Andrei Alexandrescu and...@metalanguage.com 2010-06-08 07:57:32 PDT --- Good ideas. I think we can break std.find into several constrained templates, each with its own documentation - something like std.conv.to. Also, we could and should use auto return types for the win. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3441] Snow Leopard: Static constructors do not work
http://d.puremagic.com/issues/show_bug.cgi?id=3441 Sean Kelly s...@invisibleduck.org changed: What|Removed |Added Status|NEW |RESOLVED CC||s...@invisibleduck.org Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3441] Snow Leopard: Static constructors do not work
http://d.puremagic.com/issues/show_bug.cgi?id=3441 --- Comment #1 from Sean Kelly s...@invisibleduck.org 2010-06-08 10:07:23 PDT --- Verified as fixed against DMD 2.046. I'll look at DMD1x as well to be sure. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4295] New: IID_IUnknown symbol undefined in phobos.lib
http://d.puremagic.com/issues/show_bug.cgi?id=4295
Summary: IID_IUnknown symbol undefined in phobos.lib
Product: D
Version: 2.041
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: link-failure, rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r mrmoc...@gmx.de 2010-06-08 10:24:18 PDT ---
std.c.windows.windows defines extern IID IID_IUnknown (and later uses it in
ComObject)
but the linker complains that the symbol is undefined.
Replacing it with
IID IID_IUnknown = {0x, 0x, 0x, [0xC0, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x46]};
makes it work, but I'm not sure if this is the correct GUID.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4295] IID_IUnknown symbol undefined in phobos.lib
http://d.puremagic.com/issues/show_bug.cgi?id=4295 --- Comment #3 from Trass3r mrmoc...@gmx.de 2010-06-08 11:30:20 PDT --- Just found out that pragma(lib, uuid) is actually present in std.windows.iunknown! But this one is more or less obsolete. std.c.windows.com contains more functionality and also the ComObject class that is mentioned in the docs IIRC. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4296] New: Reduce parasitic error messages
http://d.puremagic.com/issues/show_bug.cgi?id=4296
Summary: Reduce parasitic error messages
Product: D
Version: 2.041
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2010-06-08 11:34:05 PDT ---
The test case below generates many spurious error messages. In the beta of
2.047, they have references to type _error. Now that there is a distinct error
type, it is straightforward to eliminate them all.
Most occur in expression.c. For example, all the checkXXX() functions should
start with:
if (type == Type::terror)
return new ErrorExp();
Likewise cases such as:
void BinExp::incompatibleTypes()
{
+if (e1-type == Type::terror || e2-type == Type::terror)
+return;
--
TEST CASES
--
void error_message_tests()
{
int x = y * 1;
x = 4 + y;
int *p = *y;
x = y++;
x = 7 - y;
x = y[3];
x = ++y;
x = y ? 2 : 3;
x = null[y];
x = p[y..y];
y += y;
x = y/1; // and where the heck did those two divs by 0 come from
x = y ~ y;
x ~= y;
x = !y;
x = 3 in y;
x = y is 2;
x = y ^^ 2;
x ^^= y;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4177] __ctfe can't be used in pure functions
http://d.puremagic.com/issues/show_bug.cgi?id=4177 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||patch CC||clugd...@yahoo.com.au Version|future |2.041 --- Comment #1 from Don clugd...@yahoo.com.au 2010-06-08 11:38:37 PDT --- Since __ctfe is so magical and unique, it seems justified to give it one more special case. Other approaches I tried (changing the storage_class of __ctfe) were far more complicated. PATCH expression.c, VarExp::semantic(), line 4397. +/* Magic variable __ctfe never violates pure or safe + */ +if (v-ident == Id::ctfe) +return this; /* If ANY of its enclosing functions are pure, * it cannot do anything impure. * If it is pure, it cannot access any mutable variables other * than those inside itself */ -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3428] OSX 10.6.1 Access violation when writing to global variables
http://d.puremagic.com/issues/show_bug.cgi?id=3428 --- Comment #4 from Christopher O'Neill digitalm...@chrisoneill.co.uk 2010-06-08 12:10:21 PDT --- The original bug report was filed against DMD1, not DMD2. However, I can confirm that this bug is indeed fixed in DMD v1.061. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #12 from Sean Kelly s...@invisibleduck.org 2010-06-08 12:22:20 PDT --- Yeah, the patch doesn't work any more. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3806] TypeInfo_Const has member base in object_.d and member next in object.di
http://d.puremagic.com/issues/show_bug.cgi?id=3806 --- Comment #1 from Sean Kelly s...@invisibleduck.org 2010-06-08 13:08:01 PDT --- There appears to be little consistency with this field for TypeInfo. Some have a next member, some have a base member, and some have an m_next member. I'm afraid I'll break something if I change this, so I'm reassigning to Walter. Ideally, all TypeInfo classes will use the same name (like base) for the member variable and override next() appropriately. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3779] [123][0][$-1] causes __dollar unresolved in compile-time.
http://d.puremagic.com/issues/show_bug.cgi?id=3779 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||link-failure, rejects-valid OS/Version|Mac OS X|All --- Comment #3 from Don clugd...@yahoo.com.au 2010-06-08 14:19:09 PDT --- Even simpler test case: static const E=[123][0][$-1]; bug.d(1): Error: non-constant expression ([123][0u])[__dollar - 1u] This is a constant-folding issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4297] New: Nothrow functions cannot use constant dynamic array
http://d.puremagic.com/issues/show_bug.cgi?id=4297
Summary: Nothrow functions cannot use constant dynamic array
Product: D
Version: 2.041
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro rsi...@gmail.com 2010-06-08 15:32:21 PDT
---
DMD rejects nothrow functions which use compile-time constant dynamic array for
violating nothrow.
immutable TABLE = [ 1, 2, 3 ];
pragma(msg, typeof(TABLE)); // immutable(int[])
void foo() nothrow
// Error: function test.foo 'foo' is nothrow yet may throw
{
const(int)[] tab;
tab = TABLE;
}
The error does not occur if TABLE is declared with auto or immutable int[3]
(instead of mere immutable).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4298] New: Constant array translated to unnecessary array literal creation
http://d.puremagic.com/issues/show_bug.cgi?id=4298
Summary: Constant array translated to unnecessary array literal
creation
Product: D
Version: 2.041
Platform: x86
OS/Version: All
Status: NEW
Keywords: performance
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rsi...@gmail.com
--- Comment #0 from Shin Fujishiro rsi...@gmail.com 2010-06-08 17:57:52 PDT
---
Using constant (const or immutable) dynamic array causes unnecessary
array literal creation if the constant array has an initializer.
This behavior degrades performance, and also causes the bug 4297.
Test code and the disassembled output:
immutable int[] TABLE = [ 1, 2, 3 ];
void foo()
{
const(int)[] tab = TABLE;
}
_D4test3fooFZv:
pushEBP
movEBP,ESP
pushEBX
push3
push2
push1
push3
movEAX,offset FLAT:_d12typeinfo_axi6__in...@sym32
pushEAX
call _d_arrayliter...@pc32
movECX,EAX
movEBX,3
addESP,014h
popEBX
popEBP
ret
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4298] Constant array translated to unnecessary array literal creation
http://d.puremagic.com/issues/show_bug.cgi?id=4298
Shin Fujishiro rsi...@gmail.com changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Shin Fujishiro rsi...@gmail.com 2010-06-08 18:02:25 PDT
---
Patch against DMD r526:
--- src/optimize.c
+++ src/optimize.c
@@ -58,10 +58,9 @@ Expression *expandVar(int result, VarDeclaration *v)
return e;
}
-Type *tb = v-type-toBasetype();
if (result WANTinterpret ||
v-storage_class STCmanifest ||
-(tb-ty != Tsarray tb-ty != Tstruct)
+v-type-isscalar()
)
{
if (v-init)
The if condition is changed so that only scalar constants are expanded.
Affected types are Tarray, Taarray, Tclass and Tdelegate. Arrays and
associative arrays should not be expanded (the reported problem); classes and
delegates are not necessary to be expanded.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4003] The result changes only with the order of source files.
http://d.puremagic.com/issues/show_bug.cgi?id=4003 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-06-08 21:49:03 PDT --- http://www.dsource.org/projects/dmd/changeset/527 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
