[Issue 7130] NRVO Bug: Wrong Code With D'tor + Conditional Return
http://d.puremagic.com/issues/show_bug.cgi?id=7130
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||DUPLICATE
--- Comment #1 from Kenji Hara k.hara...@gmail.com 2012-05-10 23:05:16 PDT ---
(In reply to comment #0)
Both D'tors are called and the returned result lives at a different address
after being returned than before, as expected if not using NRVO. On the other
hand, no postblit being called for whichever struct is returned, as expected
if
using NRVO.
The function 'doit' cannot NRVO, because s1 and s2 should have different
addresses.
S doIt(int i) {
S s1;
S s2;
printf(s1 lives at %p.\n, s1);
printf(s2 lives at %p.\n, s2);
return (i == 42) ? s1 : s2; // postblit should run
}
I'll make this a dup of bug 7516. I have posted more better test code in there.
*** This issue has been marked as a duplicate of issue 7516 ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7516] Postblit not called for structs returned from a ternary operator
http://d.puremagic.com/issues/show_bug.cgi?id=7516 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #4 from Kenji Hara k.hara...@gmail.com 2012-05-10 23:05:16 PDT --- *** Issue 7130 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 8069] incorrect ambiguous virtual function error
http://d.puremagic.com/issues/show_bug.cgi?id=8069 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Kenji Hara k.hara...@gmail.com 2012-05-11 01:38:18 PDT --- D1 fix: https://github.com/D-Programming-Language/dmd/commit/30909d9ba663c4ed33684e34584984bfaaf85ee9 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8082] New: Invalid error messages based on module compilation order
http://d.puremagic.com/issues/show_bug.cgi?id=8082
Summary: Invalid error messages based on module compilation
order
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2012-05-11
02:56:30 PDT ---
main.d that references an undefined function:
module main;
void main() {
test(); // invalid call
}
and util.d:
module util;
import std.algorithm;
bool canFindAny(string[] inputs, string target1)
{
foreach (input; inputs)
{
if (target1.canFind(input))
return true;
}
return false;
}
$ dmd main.d util.d
main.d(4): Error: undefined identifier test
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(2837): Error: template
std.algorithm.find does not match any function template declaration
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(2837): Error: template
std.algorithm.find cannot deduce template function from argument types !(a ==
b,ubyte[],ubyte[])(ubyte[],ubyte[])
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(2836): Error: template
instance find!(a == b,ubyte[],ubyte[]) errors instantiating template
Only the first error message should appear. If you comment out the call to
test() in main.d, all errors are gone.
Note that the order of compiling the modules changes the behavior, see:
$ dmd util.d main.d
$ main.d(4): Error: undefined identifier test
$ dmd main.d util.d
$ main.d(4): Error: undefined identifier test
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(2837): Error: template
std.algorithm.find does not match any function template declaration
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(2837): Error: template
std.algorithm.find cannot deduce template function from argument types !(a ==
b,ubyte[],ubyte[])(ubyte[],ubyte[])
D:\DMD\dmd2\windows\bin\..\..\src\phobos\std\algorithm.d(2836): Error: template
instance find!(a == b,ubyte[],ubyte[]) errors instantiating template
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4838] Cannot declare a delegate variable for const member functions
http://d.puremagic.com/issues/show_bug.cgi?id=4838
SHOO zan77...@nifty.com changed:
What|Removed |Added
CC||zan77...@nifty.com
--- Comment #9 from SHOO zan77...@nifty.com 2012-05-11 03:09:41 PDT ---
This bug is very important for const/shared/immutable correctness.
The following code is caused by this issue clearly:
-
class A {
int x;
void foo() { x = 1; }
}
void bar(void delegate() dg) {
dg();
}
void main() {
immutable a = new immutable(A);
assert(a.x == 0);
bar(a.foo); // This line should be compilation error.
assert(a.x == 0); // core.exception.AssertError@main(14): Assertion
failure
}
-
Its workaround is the following code:
-
class A {
int x;
void foo() { x = 1; }
}
alias typeof((new class(){void foo() const{}}).foo) void_delegate_const;
void bar(void_delegate_const dg) {
dg();
}
void main() {
immutable a = new immutable(A);
assert(a.x == 0);
bar(a.foo); // main.d(14): Error: function main.bar (void delegate()
const dg) is not callable using argument types (void delegate())
assert(a.x == 0);
}
-
It is painful to write such correct code.
Fortunately, there is a PullRequest, so I hope to be merged as soon as
possible.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8083] New: Throwing in a loop results in infinite bypassing exception messages
http://d.puremagic.com/issues/show_bug.cgi?id=8083
Summary: Throwing in a loop results in infinite bypassing
exception messages
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2012-05-11
14:33:14 MSD ---
---
import std.stdio;
void main() {
// for (auto bc = File.ByChunk(File(), 1); ; ) { } // as expected
// for (auto bc = File().byChunk(1); false; ) { } // as expected
for (auto bc = File().byChunk(1); ; ) { } // infinite loop
foreach(line; File().byLine()) { }// infinite loop too
}
---
It writes this in infinite loop:
Bypasses std.exception.ErrnoException@std\stdio.d(288)
=== Bypassed ===
std.exception.ErrnoException@std\stdio.d(288): Cannot open file `' in mode `rb'
(No error)
Not sure is it dmd or druntime issue.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
std.concurrency and module constructors
OS: Windows 7 64bit
Compiler: DMD32 D Compiler v2.059
Using spawn in module constructor causes very strange behavior.
import std.concurrency;
import std.stdio;
void main() {
}
void worker() {
receiveOnly!OwnerTerminated;
}
static this() {
writeln(module constructor);
spawn(worker);
}
static ~this() {
writeln(module destructor);
}
prints in console:
module constructor
module destructor
module constructor
module destructor
module constructor
module constructor
module constructor
module constructor
module constructor
...
Re: std.concurrency and module constructors
On Fri, 11 May 2012 07:34:46 -0400, japplegame jappleg...@gmail.com
wrote:
OS: Windows 7 64bit
Compiler: DMD32 D Compiler v2.059
Using spawn in module constructor causes very strange behavior.
import std.concurrency;
import std.stdio;
void main() {
}
void worker() {
receiveOnly!OwnerTerminated;
}
static this() {
writeln(module constructor);
spawn(worker);
}
static ~this() {
writeln(module destructor);
}
prints in console:
module constructor
module destructor
module constructor
module destructor
module constructor
module constructor
module constructor
module constructor
module constructor
...
This list is for bugzilla to post to, it is not for general bug reports or
help requests. I really wish it was disabled to post to from everyone but
bugzilla.
Please repost your issue to D.learn.
Thanks
-Steve
Re: std.concurrency and module constructors
Oh, I'm sorry. My mistake.
[Issue 7243] Compiler should call separate function when allocating a struct on the heap
http://d.puremagic.com/issues/show_bug.cgi?id=7243 --- Comment #7 from github-bugzi...@puremagic.com 2012-05-11 10:48:13 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/7375e9098e7852cd333d3ed6d211aa3eaf719352 Merge pull request #202 from schveiguy/issue7243 Implement druntime functions for allocating individual structs on the heap. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7243] Compiler should call separate function when allocating a struct on the heap
http://d.puremagic.com/issues/show_bug.cgi?id=7243 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8084] New: std.stdio.ByLine is not true input range
http://d.puremagic.com/issues/show_bug.cgi?id=8084
Summary: std.stdio.ByLine is not true input range
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: k.hara...@gmail.com
--- Comment #0 from Kenji Hara k.hara...@gmail.com 2012-05-11 10:55:07 PDT ---
version(A) and version(B) should output same result, but A is completely
broken.
import std.array;
import std.stdio;
void main()
{
string fname = __FILE__;
version(A)
{
auto lines = File(fname).byLine().array();
foreach (ln; lines)
writeln(ln);
}
version(B)
{
foreach (ln; File(fname).byLine())
writeln(ln);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8085] New: std.algorithm.joiner makes invalid assumptions about front()
http://d.puremagic.com/issues/show_bug.cgi?id=8085
Summary: std.algorithm.joiner makes invalid assumptions about
front()
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@digitalmars.com
--- Comment #0 from Walter Bright bugzi...@digitalmars.com 2012-05-11
12:05:54 PDT ---
Given the program:
=
import std.stdio;
import std.ascii;
import std.algorithm;
import std.string;
void main() {
//stdin.byChunk(1024).joiner().map!(a =
toUpper(a)).copy(stdout.lockingTextWriter());
stdin.byLine(KeepTerminator.yes).joiner().map!(a =
toUpper(a)).copy(stdout.lockingTextWriter());
//stdin.byLine(KeepTerminator.yes).joiner().copy(stdout.lockingTextWriter());
//stdin.byLine(KeepTerminator.yes).copy(stdout.lockingTextWriter());
}
==
Compile run with:
foo foo.d
trying one of the 4 versions. Versions 1 and 4 work, 2 and 3 fail
horribly.
The output is all scrambled, like this:
IMPORT STD.ASCII;
IMPORT STD.ALGORITIMPORT STD.STRING;
M;
MPORT STD.STRING;
VVOID MAIN() {
STDIN.BYLINE(KEEPTERMINATOR.YES).JOINER().MAP!(A =
TOUPPER(A)).COPY(STDOUT.LOCKINGTEXT //STDIN.B
YLINE(KEEPTERMINATOR.YES).JOINER().COPY(STDOUT.LOCKINGTEXTWRITER());
CKINGTEXTWRITER());
//STDIN.BYLINE(KEEPTERMINATOR.YES).COPY(STDOUT.LOCKINGTEXTWRITER());
ITER());
}
//STDIN.BYLINE(KEEPTERMINATOR.YES).COPY(STDOUT.LOCKINGTEXTWRITER());
}
Analysis from Andrei:
Go to algorithm.d line 2370, when joiner() is defined. Then go down to method
prepare(). That method calls _items.front.empty, i.e. it assumes _items.front
works but at the same time saves _current. At the moment _items.front is
called, _current gets overwritten.
The code should be changed to not assume that _items.front is independent from
_current.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8084] std.stdio.ByLine is not true input range
http://d.puremagic.com/issues/show_bug.cgi?id=8084 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution||WONTFIX --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2012-05-11 12:10:30 PDT --- In order for byLine to be efficient, it must reuse the buffer it's reading. In order for the above code to be equivlent, it must dup every line, which is hugely inefficient if you aren't going to use them beyond the scope of the foreach statement. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8086] New: std.stdio is underdocumented
http://d.puremagic.com/issues/show_bug.cgi?id=8086
Summary: std.stdio is underdocumented
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@digitalmars.com
--- Comment #0 from Walter Bright bugzi...@digitalmars.com 2012-05-11
12:13:37 PDT ---
1. byLine is documented to return a LinesReader, but that is the only
mention of LinesReader anywhere
2. stdin and stdout are mentioned in passing several times, but they need their
own entries explaining what they are
3. LinesReader should say that it has an element type of dchar, decoding UTF8
as required
4. The canoncial program to read from stdin and write to stdout should be given
as an example:
import std.stdio;
import std.algorithm;
void main() {
stdin.byChunk(1024).copy(stdout.lockingTextWriter());
}
5. byChunk should document what its element type is
6. byDchar is undocumented
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8087] New: Improve clarity of std.algorithm documentation
http://d.puremagic.com/issues/show_bug.cgi?id=8087 Summary: Improve clarity of std.algorithm documentation Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bugzi...@digitalmars.com --- Comment #0 from Walter Bright bugzi...@digitalmars.com 2012-05-11 12:21:36 PDT --- 1. copy's prototype is: Range2 copy(Range1, Range2)(Range1 source, Range2 target); It would be more self-documenting written as: OutputRange copy(InputRange, OutputRange)(InputRange source, OutputRange target); In general, for all the algorithms that deal with ranges, the range types should be named after the type of range expected - ForwardRange, InputRange, BidirectionalRange, etc. 2. map has inconsistent use of element names - calling it x in the description and e in the example code. Should use the same name in each. Check other descriptions for similar issues. 3. joiner should include a See Also link to the very similar std.range.chain -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Procedure entry point RtlCaptureContext could not be located
Here is the complete message:
The procedure entry point RtlCaptureContext could not be located in the
dynamic link library KERNEL32.dll
Here is my program:
int main(char[][] args) {
return(0);
}
That's it. That's the whole thing. I recently read about the D language when I
was looking up some information for a C program I'm writing, and it looks very
interesting (I also use Perl heavily, and I liked some of the ideas about D;
seems kind of like C and some really good aspects of Perl in one language) so
I wanted to try it out, so I downloaded it. Unfortunately, apparently I can't
use it.
I'm on a Windows 2000 Professional SP4 machine.
Re: Procedure entry point RtlCaptureContext could not be located
On 5/11/2012 12:39 PM, Steve Greene wrote:
Here is the complete message:
The procedure entry point RtlCaptureContext could not be located in the
dynamic link library KERNEL32.dll
Here is my program:
int main(char[][] args) {
return(0);
}
That's it. That's the whole thing. I recently read about the D language when I
was looking up some information for a C program I'm writing, and it looks very
interesting (I also use Perl heavily, and I liked some of the ideas about D;
seems kind of like C and some really good aspects of Perl in one language) so
I wanted to try it out, so I downloaded it. Unfortunately, apparently I can't
use it.
I'm on a Windows 2000 Professional SP4 machine.
1. This newsgroup is just an echo for bugzilla, bug reports should go to
bugzilla instead. Few read this group.
2. dmd no longer supports Win2K. It was necessary to drop support for it in
order to rely on numerous bug fixes in Windows since then.
[Issue 4900] compiler still slow due to a single function
http://d.puremagic.com/issues/show_bug.cgi?id=4900 Trass3r mrmoc...@gmx.de changed: What|Removed |Added CC||mrmoc...@gmx.de --- Comment #3 from Trass3r mrmoc...@gmx.de 2012-05-11 21:50:48 CEST --- Is this still the case? There was this commit: https://github.com/D-Programming-Language/dmd/commit/b329817 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8026] Fix or disallow randomShuffle() on fixed-sized arrays
http://d.puremagic.com/issues/show_bug.cgi?id=8026 Vidar Wahlberg cani...@exent.net changed: What|Removed |Added CC||cani...@exent.net --- Comment #3 from Vidar Wahlberg cani...@exent.net 2012-05-11 13:27:59 PDT --- (In reply to comment #1) Well, that's certainly weird. Range-based functions don't normally take static arrays, and I'd argue that they shouldn't, given the problems surrounding slicing static arrays (it's fine to do it, but you need to be aware of what you're doing) - though randomShuffle doesn't have the same problem as most range-based functions do with static arrays given that it's void. Still, I'd argue that it's probably better for it to require slicing like all the rest. Are the problems surrounding slicing static arrays easily explainable? From my point of view (fairly new to the language) it's confusing that you can pass a dynamic array to a Range-based function, while you'll need to slice a static array if you want to pass that data to a such function. To me it seems more user friendly if you could pass even static arrays to such method, but I presume there's a good reason why this is avoided. I haven't quite managed to figure out this yet, any pointers would be appreciated. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8026] Fix or disallow randomShuffle() on fixed-sized arrays
http://d.puremagic.com/issues/show_bug.cgi?id=8026
--- Comment #4 from Jonathan M Davis jmdavisp...@gmx.com 2012-05-11 15:39:26
PDT ---
http://stackoverflow.com/questions/8873265/is-a-static-array-a-forward-range
A static array is a value type. It owns its own memory. It's a container, not a
range.
A dynamic array is a reference type. It does _not_ own its own memory (the
runtime does). It is _not_ a container. It _is_ a range.
If I do
int[] func()
{
auto arr = [1, 2, 3, 4, 5];
return find(arr, 3);
}
there is _zero_ difference between passing arr and passing arr[]. In either
case, you're slicing the whole array. And the array being returned is a slice
of arr ([3, 4, 5] to be exact) whose memory is on the heap, owned by the
runtime.
If I do
int[] func()
{
int[5] arr = [1, 2, 3, 4, 5];
return find(arr[], 3);
}
I've now allocated a static array _on the stack_. Passing arr to a function
would copy it (since it's a value type). Passing arr[] to a function would
slice it, which means passing a reference to the static array. Now look at what
func returns. It's returning a slice of arr, which is a _local variable_ _on
the stack_. What you've done is the equivalent of
int* func()
{
int i;
return i;
}
You've returned a reference/pointer to a local variable which no longer exists.
Bad things will happen if you do this. So, the semantics of dealing with
dynamic and static arrays are _very_ different. Slicing a static array in the
wrong place can lead to major bugs, whereas slicing a dynamic array is
perfectly safe.
Now, as to range-based functions in general. They're templated functions. That
means that they use IFTI (implicit function template instantiation) - i.e. it
infers the type. So, if you have
auto func(T)(T foo)
{
...
}
int[] dArr;
int[5] sArr;
foo(dArr);
foo(sArr);
T is going to be inferred as the _exact type_ that you pass in. So, in the
first case, func gets instantiated as
auto func(int[] foo)
{
...
}
whereas in the second, it gets instantiated as
auto func(int[5] foo)
{
...
}
int[] is a range, int[5] is not. So, if func is a range-based function, it
should have a template constraint on it, and the static array will fail that
constraint.
auto func(T)(T foo)
if(isInputRange!T)
{
...
}
Static arrays are _not_ ranges and _cannot_ be ranges. At their must basic
level (the input range), ranges must implement empty, front, and popFront, and
static arrays _cannot_ implement popFront, because you cannot change their
length. The _only_ way that a static array can be passed to a range-based
function is if it's sliced so that you have a dynamic array (which _is_ a
range). And as templates take the _exact_ type, no templated function will
automatically slice a static array for you. The language _could_ be changed so
that IFTI treated static arrays as dynamic arrays and automatically sliced
them, but then you'd have problems creating templated functions that actually
wanted to take static arrays rather than dynamic ones.
You _could_ overload every range-based function with an overload specifically
for dynamic arrays (with the idea that the static array would be sliced when
it's passed to it as happens with non-templated functions which take dynamic
arrays), but that would be a royal pain. It would also significantly increase
the risk of using static arrays, because you'd end up returning ranges which
reference the static array from whatever range-based function you called, and
the fact that you're dealing with a static array could very quickly become
buried (easily resulting in returning a range to a static array which then no
longer exists, because it was a local variable). It's much better to require
that the programmer explicitly slice the static array, because then they know
that they're slicing it and then can know that they have to watch to make sure
that no reference to that static array escapes.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3449] const and invariant struct members do not behave according to spec
http://d.puremagic.com/issues/show_bug.cgi?id=3449
Masahiro Nakagawa repeate...@gmail.com changed:
What|Removed |Added
CC||repeate...@gmail.com
--- Comment #13 from Masahiro Nakagawa repeate...@gmail.com 2012-05-11
18:30:07 PDT ---
I hit this issue in my new library.
I have a following struct.
struct Option
{
string name;
string[] fields;
immutable type = hoge;
}
My library automatically converts such struct to JSON.
But type field does not exist (tupleof does not return immutable field).
expect:
{fields: [a'], unique: false, type: hoge}
actual:
{fields: [a'], unique: false}
Currently, I remove immutable keyword temporally but 'type' should be
immutable.
Is there a better solution?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 123] Use of function, modulus, and dollar sign (length) fails to compile with static and const
http://d.puremagic.com/issues/show_bug.cgi?id=123 --- Comment #4 from github-bugzi...@puremagic.com 2012-05-11 18:58:10 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a1e42aa8cb31cd218d98c5685d8848de264ddf51 Add a new DISABLED option for tests Sometimes is useful to be able to add tests even when they don't pass. Being able to do so, makes life easier for people wanting to fix the bug (they have the test right there) and ensures people don't forget to add test cases just because it would break the auto-tester. Now tests can have a DISABLED option which should have a reason why the test was disabled. For example: // DISABLED: bug 123 is still not fixed When a test is disabled, a special message is printed, for example: !!! runnable/bug123.d () [DISABLED: bug 123 is still not fixed] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7546] 64-bit floating-point issue with negative zero: -0.0 == 0.0 is false.
http://d.puremagic.com/issues/show_bug.cgi?id=7546 --- Comment #3 from github-bugzi...@puremagic.com 2012-05-11 19:02:54 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a8ffc8ab60aa3e1ae965e5764f0900e14a0881c1 Fix issue 7546 64-bit floating-point issue with negative zero: -0.0 == 0.0 is false Just duplicate the code for float == float. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 64] Unhandled errors should go to stderr
http://d.puremagic.com/issues/show_bug.cgi?id=64 --- Comment #9 from github-bugzi...@puremagic.com 2012-05-11 19:02:58 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a8ffc8ab60aa3e1ae965e5764f0900e14a0881c1 Fix issue 7546 64-bit floating-point issue with negative zero: -0.0 == 0.0 is false Just duplicate the code for float == float. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8088] New: Inline assembler: Indexing struct fields not possible
http://d.puremagic.com/issues/show_bug.cgi?id=8088
Summary: Inline assembler: Indexing struct fields not possible
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: verylonglogin@gmail.com
--- Comment #0 from Denis Shelomovskij verylonglogin@gmail.com 2012-05-12
07:37:14 MSD ---
Example from http://dlang.org/iasm.html:
---
struct Foo { int a,b,c; }
int bar(Foo *f) {
asm {
mov EBX, f;
mov EAX, Foo.b[EBX];
}
}
---
main.d(5): Error: variable b cannot be read at compile time
Also see Issue 5302
Workaround: add .offsetof
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
