[Issue 3154] foreach corrupting data returned by ref functions.
http://d.puremagic.com/issues/show_bug.cgi?id=3154 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||wrong-code Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #1 from Don clugd...@yahoo.com.au 2010-05-06 23:53:17 PDT --- Fixed DMD 2.034. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3149] volatile instead of synchronized
http://d.puremagic.com/issues/show_bug.cgi?id=3149 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Version|unspecified |2.008 Resolution||FIXED --- Comment #1 from Don clugd...@yahoo.com.au 2010-05-06 23:59:30 PDT --- Fixed DMD 2.013. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2868] provide runtime facility for reflection. opDot compiletime dispatch facility
http://d.puremagic.com/issues/show_bug.cgi?id=2868 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #3 from Don clugd...@yahoo.com.au 2010-05-07 00:23:23 PDT --- opDispatch was added in DMD2.037. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4077] Bugs caused by bitwise operator precedence
http://d.puremagic.com/issues/show_bug.cgi?id=4077 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #9 from Don clugd...@yahoo.com.au 2010-05-07 02:01:48 PDT --- (In reply to comment #5) The precedence of bitwise operators is indeed counter-intuitive. Presumably there's a reason C defined them this way. Yes, there is -- backwards compatibility with the B language!!! Denis Ritchie says (http://cm.bell-labs.com/cm/cs/who/dmr/chist.html): At the suggestion of Alan Snyder, I introduced the and || operators to make the mechanism [[short circuit evaluation]] more explicit. Their tardy introduction explains an infelicity of C's precedence rules. In B one writes if (a==b c) ... to check whether a equals b and c is non-zero; in such a conditional expression it is better that have lower precedence than ==. In converting from B to C, one wants to replace by in such a statement; to make the conversion less painful, we decided to keep the precedence of the operator the same relative to ==, and merely split the precedence of slightly from . Today, it seems that it would have been preferable to move the relative precedences of and ==, and thereby simplify a common C idiom: to test a masked value against another value, one must write if ((amask) == b) ... where the inner parentheses are required but easily forgotten. --- So C did it for an unbelievably silly reason (there was hardly any B code in existence). Note that Ritchie says it is easily forgotten. We should definitely fix this ridiculous precedence. (IMHO it was very sloppy that ANSI C didn't make (ab == c) an error). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 314] [module] Static, renamed, and selective imports are always public
http://d.puremagic.com/issues/show_bug.cgi?id=314 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #12 from nfx...@gmail.com 2010-05-07 02:14:37 PDT --- Whenever I compile some code in ldc, that has been developed with dmd, I get compilation errors related to this bug. That's because ldc (at least partially) fixed it. As far as I can tell, ldc never rejected actually valid code related to this bug. It's a bit ridiculous. What keeps back the patches going into dmd? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 314] [module] Static, renamed, and selective imports are always public
http://d.puremagic.com/issues/show_bug.cgi?id=314 Tomas Lindquist Olsen to...@famolsen.dk changed: What|Removed |Added CC||to...@famolsen.dk --- Comment #13 from Tomas Lindquist Olsen to...@famolsen.dk 2010-05-07 02:42:38 PDT --- stubbornness ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4009] OPTLINK ruins the day yet again
http://d.puremagic.com/issues/show_bug.cgi?id=4009 nfx...@gmail.com changed: What|Removed |Added Keywords||link-failure Priority|P2 |P1 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4009] OPTLINK ruins the day yet again
http://d.puremagic.com/issues/show_bug.cgi?id=4009
--- Comment #3 from nfx...@gmail.com 2010-05-07 06:00:12 PDT ---
In dmd 1.060, the example above doesn't crash anymore, but this does:
--- x.d
template Tuple(T...) {
alias T Tuple;
}
template Repeat(int count) {
static if (!count) {
alias Tuple!() Repeat;
} else {
alias Tuple!(count-1, Repeat!(count-1)) Repeat;
}
}
void sometemplate(int T)() {
foreach (x; Repeat!(320)) {
sometemplate!(T)();
}
}
void main() {
foreach (x; Repeat!(498)) {
sometemplate!(x)();
}
}
---
wine dmd x.d -g
Unexpected OPTLINK Termination at EIP=0041338F
EAX=020A EBX=020A ECX= EDX=65D474DD
ESI=0033FE7C EDI=65D474DD EBP=0033FED4 ESP=0033FD60
First=00402000
There's lots of similarities in the test case and register dump, so I suppose
it's the same bug.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4163] New: if(bool = bool) results in ill-worded error
http://d.puremagic.com/issues/show_bug.cgi?id=4163
Summary: if(bool = bool) results in ill-worded error
Product: D
Version: 2.041
Platform: x86
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2010-05-07
10:42:33 PDT ---
The following code:
bool x, y;
if(x = y) {}
results in the following error:
Error: '=' does not give a boolean result
Which is clearly not a correct message. A better message would be something
like:
Error: '=' cannot be used inside an if condition
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3667] Regression(D2 only): broken out(result) in contracts
http://d.puremagic.com/issues/show_bug.cgi?id=3667 --- Comment #6 from Shin Fujishiro rsi...@gmail.com 2010-05-07 11:30:35 PDT --- Created an attachment (id=624) Patch for DMD 2.045 The attached patch should fix the problem. Since DMD 2.028, result variables are marked as const. The cause of this bug is that DMD mistakenly tries to const-fold a result variable into its default initializer. Unfortunately, it succeeds when return type is a basic value type (int, bool, etc.). The attached patch adds a STCresult storage class to declaration.h, and applies it to the vresult. The STCresult is similar to the STCparameter; it disables default-value initialization of result variables. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
