2013-07-01 01:07:59 PDT ---
The example code generates wrong html.
Code:
----
///
void foo() {}
///
unittest
{
auto s = "1 + (2 * (3 + 1 / 2)";
assert(!balancedParens(s, '(', ')'));
}
----
Generated test.html
----
test
test
$(DDOC_MODULE_MEMBERS
void foo();
Examples:
auto s = "1 + (2 * (3 + 1 / 2)");
assert(!balancedParens(s, '(', ')'));
Page generated by Ddoc.
----
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 01:15:43 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 08:15:43 +0000 (UTC)
Subject: [Issue 10519] Stray-paren in doc-unittest code generates wrong
document
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10519
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
--- Comment #1 from Kenji Hara 2013-07-01 01:15:42 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2287
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 01:43:40 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 08:43:40 +0000 (UTC)
Subject: [Issue 10475] destructor is called on 'for' loop variable even when
initialization failed
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10475
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull, wrong-code
--- Comment #3 from Kenji Hara 2013-07-01 01:43:37 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2286
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 01:49:18 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 08:49:18 +0000 (UTC)
Subject: [Issue 10520] New: Building with profiler results in "is not nothrow"
error on some contracts
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10520
Summary: Building with profiler results in "is not nothrow"
error on some contracts
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: verylonglogin.reg at gmail.com
--- Comment #0 from Denis Shelomovskij 2013-07-01 12:49:17 MSD ---
Some in/out contracts causes "is not nothrow" error when building with
"-profile". The only compiler output e.g. for:
---
...
void copyFrom(R)(R r) if(isInputRange!R && is(ElementType!R == T))
out { assert(func(_buff)); }
body { _buff = r.array(); }
...
---
is:
---
..\utils.d(nnn): Error: 'utils.Type!X.Type.func' is not nothrow
---
Workaround:
Disable these contracts or move its code to function body.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 02:28:54 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 09:28:54 +0000 (UTC)
Subject: [Issue 10150] Prefix method 'this' qualifiers should be just ignored
anytime
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10150
--- Comment #14 from Dicebot 2013-07-01 02:28:51 PDT ---
(In reply to comment #11)
> Typ? "Both", then you state two different things.
Both free function and method.
> AFAIK, anything returnable can be qualified with const, so there would be no
> fall through case.
I don't know if const(void) is valid, but at least pure is applicable to return
type only when it is one of function types so it will fall through. I am not
speaking only about const, all attributes should behave consistently.
> What about:
>
> --------
> struct S
> {
> const nothrow pure
> T foo();
>
> nothrow pure const
> T bar();
> }
> --------
>
> What does (should) foo return? What about bar?
both return const(T) (at the very least, I have no idea what T is). When I am
speaking about postfix qualifier I mean "T bar() const pure nothrow"
> The current rules are obvious: stand alone attribute => Function.
> Simple and obvious.
> There is no reasons for "const" to get special treatment.
No, they are more like "stand alone attribute -> function or no-op, you'd
better be careful!". And breaks similarity with C/C++ principle. And makes your
code needlessly "Lisp-y".
Behaviour has been very confusing all the time but at least it slapped me into
face every time I tried to type stuff in a more natural syntax. Not any more.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 03:01:06 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 10:01:06 +0000 (UTC)
Subject: [Issue 7227] [] syntax for empty associative array too?
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7227
--- Comment #4 from bearophile_hugs at eml.cc 2013-07-01 03:01:04 PDT ---
yebblies commented on GitHub:
> Ideally this would not be the same as K[V] aa = null;,
> it would behave like K[V] aa = new K[V]; - an AA would be allocated.
I think this is a bad idea, because then the semantics of D code changes if you
use [] instead of null. D associative arrays have troubles:
void test(int[int] arraya, int x) {
arraya[x] = x;
}
void main() {
int[int] d;
test(d, 0);
int[int] d0;
assert(d == d0); // d is empty, 0:0 is lost
d[1] = 1;
test(d, 2);
assert(d == [1: 1, 2: 2]); // now 2:2 is not lost
}
Compared to the output of this Python code:
def test(arraya, x):
arraya[x] = x
def main():
d = {}
test(d, 0)
assert d == {0: 0}
d[1] = 1
test(d, 2)
assert d == {0: 0, 1: 1, 2: 2}
main()
Such problems should be faced in other ways. Making the associative array
literal semantics even more complex is not helping.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 04:54:51 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 11:54:51 +0000 (UTC)
Subject: [Issue 10150] Prefix method 'this' qualifiers should be just ignored
anytime
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10150
--- Comment #15 from monarchdodra at gmail.com 2013-07-01 04:54:50 PDT ---
(In reply to comment #14)
> > What about:
> >
> > --------
> > struct S
> > {
> > const nothrow pure
> > T foo();
> >
> > nothrow pure const
> > T bar();
> > }
> > --------
> >
> > What does (should) foo return? What about bar?
>
> both return const(T) (at the very least, I have no idea what T is). When I am
> speaking about postfix qualifier I mean "T bar() const pure nothrow"
Well, such a change would break existing code that is correct and respects the
spec. I'm not sure changing the semantics of such code would be acceptable. D
allows attributes to be placed either prefix or postfix. Forcing "const" to
only work right hand side is a C++ holdover. There should be no difference
where you place it. If anything, I find it weird when I find code that is
written like:
"pure @property T foo() const"
Why place the const there? Put it on the left, that's where you placed
everything else...
> > The current rules are obvious: stand alone attribute => Function.
> > Simple and obvious.
> > There is no reasons for "const" to get special treatment.
>
> No, they are more like "stand alone attribute -> function or no-op, you'd
> better be careful!". And breaks similarity with C/C++ principle.
I agree both are problem. I happen to think the better solution is that no-op
becomes explicit compile error. This is both safe, and doesn't add special
positional casing.
> And makes your
> code needlessly "Lisp-y".
Don't know lisp.
> Behaviour has been very confusing all the time but at least it slapped me into
> face every time I tried to type stuff in a more natural syntax. Not any more.
I agree we should be slapped in the face every time we type something wrong.
Currently, being slapped in the face for wrong postfix is good. Also being
slapped for wrong prefix would be better.
The solution of saying "prefix applies to return value", would be a big
interface change. Even where we to agree it is the right decision, I don't
think it could acceptable change.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 05:29:08 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 12:29:08 +0000 (UTC)
Subject: [Issue 10506] Purity should not be checked in a mixin statement
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10506
--- Comment #4 from Andrej Mitrovic 2013-07-01 05:29:06 PDT ---
(In reply to comment #3)
> This is issue 6169, which was fixed a while ago. I don't know what compiler
> version you were using but I double-checked the source and it calls
> ctfeSemantic like it should.
>
> *** This issue has been marked as a duplicate of issue 6169 ***
Let's try this:
-----
import std.string;
void test() pure
{
mixin(["int ", "x;"].join());
}
void main() {}
-----
2.061: ok
2.062: Error: pure function 'test' cannot call impure function 'join'
2.063: Error: pure function 'test' cannot call impure function 'join'
2.064: ok (but I think this is because join has become pure?)
Note that the test-case in Issue 6169 works in all of these compilers, but not
the sample I gave.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 06:00:49 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 13:00:49 +0000 (UTC)
Subject: [Issue 10506] Purity should not be checked in a mixin statement
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10506
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra at gmail.com
--- Comment #5 from monarchdodra at gmail.com 2013-07-01 06:00:47 PDT ---
(In reply to comment #4)
> (In reply to comment #3)
> > This is issue 6169, which was fixed a while ago. I don't know what compiler
> > version you were using but I double-checked the source and it calls
> > ctfeSemantic like it should.
> >
> > *** This issue has been marked as a duplicate of issue 6169 ***
>
> Let's try this:
>
> -----
> import std.string;
>
> void test() pure
> {
> mixin(["int ", "x;"].join());
> }
>
> void main() {}
> -----
>
> 2.061: ok
> 2.062: Error: pure function 'test' cannot call impure function 'join'
> 2.063: Error: pure function 'test' cannot call impure function 'join'
> 2.064: ok (but I think this is because join has become pure?)
>
> Note that the test-case in Issue 6169 works in all of these compilers, but not
> the sample I gave.
I have reopened 6169 with this usecase:
--------
string bar(string op = "+") @property
{
return "a" ~ op ~ "b";
}
void foo()()
{
int a, b;
int c = mixin(bar);
}
@safe void main()
{
foo!()();
}
--------
main.d(14): Error: safe function 'D main' cannot call system function
'main.foo!().foo'
--------
Observations:
1) The problem is only with @safe, not pure.
2) Calling "min(bar("+"))" also makes the problem go away.
--------
Not sure if this is strictly 6169 or if I should have posted here and
un-resolved as duplicate. But in any case, this is (I think) a simpler use
case.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 06:03:14 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 13:03:14 +0000 (UTC)
Subject: [Issue 10506] Purity should not be checked in a mixin statement
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10506
--- Comment #6 from yebblies 2013-07-01 23:03:13 EST ---
(In reply to comment #4)
>
> Let's try this:
>
> -----
> import std.string;
>
> void test() pure
> {
> mixin(["int ", "x;"].join());
> }
>
> void main() {}
> -----
>
> 2.061: ok
> 2.062: Error: pure function 'test' cannot call impure function 'join'
> 2.063: Error: pure function 'test' cannot call impure function 'join'
> 2.064: ok (but I think this is because join has become pure?)
>
> Note that the test-case in Issue 6169 works in all of these compilers, but not
> the sample I gave.
Ah, I think I know what's going on. Does it possibly work in 2.063 when not
using ufcs? I think it's only getting the direct calls to semantic, but some
others are being missed (eg resolveProperties)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 06:10:14 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 13:10:14 +0000 (UTC)
Subject: [Issue 10506] Purity should not be checked in a mixin statement
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10506
--- Comment #7 from Andrej Mitrovic 2013-07-01 06:10:13 PDT ---
(In reply to comment #6)
> Does it possibly work in 2.063 when not using ufcs?
No, I get the same results.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 06:30:37 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 13:30:37 +0000 (UTC)
Subject: [Issue 10475] destructor is called on 'for' loop variable even when
initialization failed
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10475
--- Comment #4 from Nils 2013-07-01 06:30:35 PDT ---
(In reply to comment #2)
> *** This issue has been marked as a duplicate of issue 8563 ***
(In reply to comment #3)
> https://github.com/D-Programming-Language/dmd/pull/2286
Does that patch fix issue 8563 or is this issue not a proper duplicate of 8563?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 06:49:48 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 13:49:48 +0000 (UTC)
Subject: [Issue 10150] Prefix method 'this' qualifiers should be just ignored
anytime
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10150
--- Comment #16 from Dicebot 2013-07-01 06:49:46 PDT ---
(In reply to comment #15)
> The solution of saying "prefix applies to return value", would be a big
> interface change. Even where we to agree it is the right decision, I don't
> think it could acceptable change.
You have asked what it my opinion about "how it should behave", not about "what
can be released" ;) I don't expect this to change, it is a design mistake with
roots too ancient to shake it. But I at least want it to remind me every time
about it, not fail silently. This pull request was a disaster.
Actually, paying even more attention to initial enhancement description I see
no valid use case. "const: void foo() {}" - this should be an error, nothing
convenient about letting it go.
P.S. By "Lisp-y" I have meant excessive () bracket usage.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 07:01:18 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 14:01:18 +0000 (UTC)
Subject: [Issue 10475] destructor is called on 'for' loop variable even when
initialization failed
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10475
--- Comment #5 from Kenji Hara 2013-07-01 07:01:17 PDT ---
(In reply to comment #4)
> (In reply to comment #2)
> > *** This issue has been marked as a duplicate of issue 8563 ***
>
> (In reply to comment #3)
> > https://github.com/D-Programming-Language/dmd/pull/2286
>
> Does that patch fix issue 8563 or is this issue not a proper duplicate of 8563?
Because I couldn't reproduce segfault in Windoes 7 64bit (== 32bit codegen)
environment. Right now I don't have x86_64 environment, so currently I don't
have enough confidence that the PR fixes bug 8563...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 07:47:24 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 14:47:24 +0000 (UTC)
Subject: [Issue 10506] Purity should not be checked in a mixin statement
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10506
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
Status|RESOLVED |REOPENED
Resolution|DUPLICATE |
--- Comment #8 from Kenji Hara 2013-07-01 07:47:23 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2289
Essentially this issue has been caused by the incomplete fix for bug 6169. But
the actual issue is very small, so I'd like to keep this independent from that.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 08:01:21 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 15:01:21 +0000 (UTC)
Subject: [Issue 6169] [CTFE] pure functions cannot compute constants using
functions not marked as pure
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6169
--- Comment #15 from Kenji Hara 2013-07-01 08:01:17 PDT ---
(In reply to comment #14)
> Not fully fixed for @safe. The conditions to reproduce are a bit complicated
> actually. It requires attribute inference, mixin and default args (!) I'm not
> sure which it is that it producing the problem:
https://github.com/D-Programming-Language/dmd/pull/2290
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 09:45:00 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 16:45:00 +0000 (UTC)
Subject: [Issue 10521] New: Struct wrong constructor chosen.
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10521
Summary: Struct wrong constructor chosen.
Product: D
Version: D1 & D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: damianday at hotmail.co.uk
--- Comment #0 from Damian 2013-07-01 09:44:59 PDT ---
// Test case, worked fine in 2.062
struct Test
{
enum DefaultSize = 256;
int size;
this(int sz = DefaultSize )
{
size = sz;
}
}
void main()
{
Test st_test;
assert(st_test.size == Test.DefaultSize); // Wrong constructor chosen!
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 09:54:39 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 16:54:39 +0000 (UTC)
Subject: [Issue 10521] Struct wrong constructor chosen.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10521
Damian changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |INVALID
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 10:16:47 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 17:16:47 +0000 (UTC)
Subject: [Issue 10521] Struct wrong constructor chosen.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10521
--- Comment #1 from Damian 2013-07-01 10:16:46 PDT ---
This is a correct test case, ignore the previous one.
Anyway tested now with Git Head and the issue has been resolved! Hooray :)
struct Test
{
enum DefaultSize = 256;
int size;
this(int sz = DefaultSize )
{
size = sz;
}
~this()
{
assert(size == DefaultSize);
}
}
public class ClassA
{
private Test st_test;
public this()
{
st_test = Test(256);
}
}
void main()
{
auto cl = new ClassA;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 10:23:23 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 17:23:23 +0000 (UTC)
Subject: [Issue 10517] readln(Char)(Char[] buf) accepts non-mutable buffers
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10517
--- Comment #1 from monarchdodra at gmail.com 2013-07-01 10:23:22 PDT ---
https://github.com/D-Programming-Language/phobos/pull/1381
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 10:41:14 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 17:41:14 +0000 (UTC)
Subject: [Issue 10510] enforce can't take an extern(C) function to call
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10510
Andrej Mitrovic changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
AssignedTo|nobody at puremagic.com |andrej.mitrovich at gmail.com
--- Comment #1 from Andrej Mitrovic 2013-07-01 10:41:13 PDT ---
https://github.com/D-Programming-Language/phobos/pull/1382
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 11:06:18 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 18:06:18 +0000 (UTC)
Subject: [Issue 10510] enforce can't take an extern(C) function to call
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10510
--- Comment #2 from github-bugzilla at puremagic.com 2013-07-01 11:06:17 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos
https://github.com/D-Programming-Language/phobos/commit/62f6459b49c5fba36eafeee7da28d440a186b915
Fix Issue 10510 - enforce should take any callable function without regard for
calling conventions.
https://github.com/D-Programming-Language/phobos/commit/141b234e5246f08d53484face5076f92df8833c2
Merge pull request #1382 from AndrejMitrovic/Fix10510
Issue 10510 - enforce should take any callable function
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 11:09:38 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 18:09:38 +0000 (UTC)
Subject: [Issue 10510] enforce can't take an extern(C) function to call
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10510
Andrej Mitrovic changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 12:01:17 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 19:01:17 +0000 (UTC)
Subject: [Issue 6646] [SafeD] array.reserve is not @safe/trusted
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6646
--- Comment #1 from hsteoh at quickfur.ath.cx 2013-07-01 12:01:16 PDT ---
IMO, reserve() should be at least @trusted. What's the use of safeD if even
language constructs like array.reserve can't be used?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 12:05:01 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 19:05:01 +0000 (UTC)
Subject: [Issue 5207] Immutability is broken in constructors
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=5207
hsteoh at quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hsteoh at quickfur.ath.cx
--- Comment #2 from hsteoh at quickfur.ath.cx 2013-07-01 12:05:00 PDT ---
Isn't this by design? In my understanding, ctors allow you to assign once, and
thereafter further assignment is prohibited. Otherwise, you couldn't have
runtime-initialized immutables, such as AA's.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 12:12:16 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 19:12:16 +0000 (UTC)
Subject: [Issue 6407] take(map) problem
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6407
hsteoh at quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hsteoh at quickfur.ath.cx
--- Comment #2 from hsteoh at quickfur.ath.cx 2013-07-01 12:12:15 PDT ---
This bug appears to be fixed in latest git HEAD (and probably last release as
well)? Bearophile, could you re-test this against the latest release and close
the bug if it doesn't happen anymore?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 12:27:29 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 19:27:29 +0000 (UTC)
Subject: [Issue 6471] std.metastrings.Format has recursive expansion problems
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6471
hsteoh at quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hsteoh at quickfur.ath.cx
--- Comment #2 from hsteoh at quickfur.ath.cx 2013-07-01 12:27:28 PDT ---
Now that std.format is CTFE-able, std.metastrings has been deprecated. Maybe
this bug can be closed?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 12:43:47 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 19:43:47 +0000 (UTC)
Subject: [Issue 10270] dmd's posix.mak has incorrect dependencies
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10270
hsteoh at quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hsteoh at quickfur.ath.cx
Resolution| |WORKSFORME
--- Comment #5 from hsteoh at quickfur.ath.cx 2013-07-01 12:43:46 PDT ---
I just did a bunch of make -j6 with DMD this weekend, and it seems to work now.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 12:49:40 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 19:49:40 +0000 (UTC)
Subject: [Issue 6407] take(map) problem
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6407
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |monarchdodra at gmail.com
Resolution| |FIXED
--- Comment #3 from monarchdodra at gmail.com 2013-07-01 12:49:39 PDT ---
(In reply to comment #2)
> This bug appears to be fixed in latest git HEAD (and probably last release as
> well)? Bearophile, could you re-test this against the latest release and close
> the bug if it doesn't happen anymore?
Works for me for as far back as at least 2.061. I'll close it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 13:27:44 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 20:27:44 +0000 (UTC)
Subject: [Issue 6646] [SafeD] array.reserve is not @safe/trusted
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6646
Steven Schveighoffer changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |schveiguy at yahoo.com
--- Comment #2 from Steven Schveighoffer 2013-07-01 13:27:43 PDT ---
It should be @trusted.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 15:00:09 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 22:00:09 +0000 (UTC)
Subject: [Issue 10522] New: __FILE__ and other special keywords cannot be used
with printf
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10522
Summary: __FILE__ and other special keywords cannot be used
with printf
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: andrej.mitrovich at gmail.com
--- Comment #0 from Andrej Mitrovic 2013-07-01 15:00:08 PDT ---
-----
import std.stdio;
void main()
{
printf("-- %s\n", __FILE__);
printf("-- %s\n", __FUNCTION__);
printf("-- %s\n", __PRETTY_FUNCTION__);
}
-----
> object.Error: Access Violation
The use-case are printf statements in destructors, which unlike writef will
avoid any allocations (which typically fail in dtors due to the GC being
stopped).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 15:37:09 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Mon, 1 Jul 2013 22:37:09 +0000 (UTC)
Subject: [Issue 10523] New: Don't call array op functions for short vector ops
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10523
Summary: Don't call array op functions for short vector ops
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: bearophile_hugs at eml.cc
--- Comment #0 from bearophile_hugs at eml.cc 2013-07-01 15:37:08 PDT ---
The D front-end performs some vector ops like a[]+b[] with a call to functions
like __arraySliceSliceAddSliceAssign_d. For more complex array operations like
a[]+b[]+c[] there is no available function, so the D front-end replaces them
with a loop.
When the vector ops are done on fixed sized arrays that are small, the back-end
of gcd and ldc2 compilers are able to produce (very) efficient code from a
loop.
So I suggest to replace _all_ vector ops with a loop when the arrays have a
length known at compile time and such length is small (where small is <= 16).
This avoids to kill the optimization opportunities for ldc2 and gdc back-ends.
And probably improves the performance of the code even for dmd compiler for
arrays like 4 integers or 4 doubles long.
This is not a general solution for this problem, but I think it's very simple
to implement, and improves significantly a wide class of common cases. I can
call it a very low hanging fruit.
- - - - - - - - - - -
Below there is some data to support my request.
The ldc2 compiler is generally a good enough optimizing compiler, it's able to
unroll loops, it should perform some vectorizations or some de-virtualizations,
it will be able to perform link-time optimization, etc.
For this small program:
import core.stdc.stdio: printf;
void main() {
double[4] a = void, b = void, c = void;
a[] = 1.0;
b[] = 2.0;
c[] = a[] + b[];
printf("%f %f %f %f\n", c[0], c[1], c[2], c[3]);
}
ldc2 gives, on a X86:
__Dmain:
pushl %ebp
movl %esp, %ebp
andl $-8, %esp
subl $136, %esp
movl $1072693248, 108(%esp)
movl $0, 104(%esp)
movl $1072693248, 116(%esp)
movl $0, 112(%esp)
movl $1072693248, 124(%esp)
movl $0, 120(%esp)
movl $1072693248, 132(%esp)
movl $0, 128(%esp)
movl $1073741824, 76(%esp)
movl $0, 72(%esp)
movl $1073741824, 84(%esp)
movl $0, 80(%esp)
movl $1073741824, 92(%esp)
movl $0, 88(%esp)
movl $1073741824, 100(%esp)
movl $0, 96(%esp)
leal 104(%esp), %eax
movl %eax, 20(%esp)
leal 72(%esp), %eax
movl %eax, 12(%esp)
leal 40(%esp), %eax
movl %eax, 4(%esp)
movl $4, 16(%esp)
movl $4, 8(%esp)
movl $4, (%esp)
calll __arraySliceSliceAddSliceAssign_d
movsd 40(%esp), %xmm0
movsd 48(%esp), %xmm1
movsd 56(%esp), %xmm2
movsd 64(%esp), %xmm3
movsd %xmm3, 28(%esp)
movsd %xmm2, 20(%esp)
movsd %xmm1, 12(%esp)
movsd %xmm0, 4(%esp)
movl $_.str, (%esp)
calll ___mingw_printf
xorl %eax, %eax
movl %ebp, %esp
popl %ebp
ret
The first group of movl are the initializations of the two arrays "a", "b" (dmd
calls __memset64 for this. But for such small arrays this can be a bit faster):
movl $1072693248, 108(%esp)
movl $0, 104(%esp)
movl $1072693248, 116(%esp)
movl $0, 112(%esp)
movl $1072693248, 124(%esp)
movl $0, 120(%esp)
movl $1072693248, 132(%esp)
movl $0, 128(%esp)
movl $1073741824, 76(%esp)
movl $0, 72(%esp)
movl $1073741824, 84(%esp)
movl $0, 80(%esp)
movl $1073741824, 92(%esp)
movl $0, 88(%esp)
movl $1073741824, 100(%esp)
Then there is a preparation for calling a druntime function that performs the
vector op, including the array lengths:
movl $4, 16(%esp)
movl $4, 8(%esp)
movl $4, (%esp)
The call:
calll __arraySliceSliceAddSliceAssign_d
And then it prepares the call to printf (I don't know why there are 8 movsd
instead of 4):
movsd 40(%esp), %xmm0
movsd 48(%esp), %xmm1
movsd 56(%esp), %xmm2
movsd 64(%esp), %xmm3
movsd %xmm3, 28(%esp)
movsd %xmm2, 20(%esp)
movsd %xmm1, 12(%esp)
movsd %xmm0, 4(%esp)
movl $_.str, (%esp)
calll ___mingw_printf
This is a similar program that uses a loop instead of vector ops:
import core.stdc.stdio: printf;
__gshared double x0 = 1.0,
x1 = 2.0,
x2 = 3.0,
x3 = 4.0,
y0 = 10.0,
y1 = 20.0,
y2 = 30.0,
y3 = 40.0;
void main() {
double[4] a = [x0, x1, x2, x3];
double[4] b = [y0, y1, y2, y3];
double[4] c = void;
foreach (i; 0 .. 4)
c[i] = a[i] + b[i];
printf("%f %f %f %f\n", c[0], c[1], c[2], c[3]);
}
Currently LLVM has some vectorization capabilities, but apparently ldc2 is not
able to use two addpd instructions (or one vaddpd) like this:
movapd 208(%esp), %xmm0
movapd 224(%esp), %xmm1
addpd 176(%esp), %xmm0
addpd 192(%esp), %xmm1
movhpd %xmm1, 28(%esp)
movlpd %xmm1, 20(%esp)
movhpd %xmm0, 12(%esp)
movlpd %xmm0, 4(%esp)
movl $_.str, (%esp)
calll ___mingw_printf
So currently ldc2 generates code like this for the manual loop, with four
addsd:
movsd 136(%esp), %xmm0
movsd 144(%esp), %xmm1
addsd 104(%esp), %xmm0
addsd 112(%esp), %xmm1
movsd 152(%esp), %xmm2
addsd 120(%esp), %xmm2
movsd 160(%esp), %xmm3
addsd 128(%esp), %xmm3
movsd %xmm3, 28(%esp)
movsd %xmm2, 20(%esp)
movsd %xmm1, 12(%esp)
movsd %xmm0, 4(%esp)
movl $_.str, (%esp)
calll ___mingw_printf
Even four addsd are faster than the call to __arraySliceSliceAddSliceAssign_d.
I think the cause of the problem is that the back-end of ldc2 doesn't receive
the lengths (that are 4) of the arrays, that are known at compile-time. A
simple solution is just to not call functions like
__arraySliceSliceAddSliceAssign_d when the length of the arrays is known to be
small, and just inline a small loop. The D front-end is already able to do this
when there is no run-time function available:
import core.stdc.stdio: printf;
__gshared double x0 = 1.0,
x1 = 2.0,
x2 = 3.0,
x3 = 4.0,
y0 = 10.0,
y1 = 20.0,
y2 = 30.0,
y3 = 40.0,
z0 = 100.0,
z1 = 200.0,
z2 = 300.0,
z3 = 400.0;
void main() {
double[4] a = [x0, x1, x2, x3];
double[4] b = [y0, y1, y2, y3];
double[4] c = [z0, z1, z2, z3];
double[4] d = void;
foreach (i; 0 .. 4)
d[i] = a[i] + b[i] + c[i];
printf("%f %f %f %f\n", d[0], d[1], d[2], d[3]);
}
movsd 200(%esp), %xmm0
movsd 208(%esp), %xmm1
addsd 168(%esp), %xmm0
addsd 176(%esp), %xmm1
addsd 144(%esp), %xmm1
movsd 216(%esp), %xmm2
addsd 184(%esp), %xmm2
addsd 152(%esp), %xmm2
movsd 224(%esp), %xmm3
addsd 192(%esp), %xmm3
addsd 160(%esp), %xmm3
movsd 136(%esp), %xmm4
movsd %xmm3, 28(%esp)
movsd %xmm2, 20(%esp)
movsd %xmm1, 12(%esp)
addsd %xmm0, %xmm4
movsd %xmm4, 4(%esp)
movl $_.str, (%esp)
calll ___mingw_printf
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 17:12:27 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 00:12:27 +0000 (UTC)
Subject: [Issue 6471] std.metastrings.Format has recursive expansion problems
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6471
--- Comment #3 from Ellery Newcomer 2013-07-01 17:12:25 PDT ---
Depends on whether you consider it a dmd issue or a phobos issue.
I just took a second look at this and.. you get a recursion depth of exactly
500 for templates. I don't recall this restriction being documented anywhere,
so if it isn't, it should be, and after that maybe take up the question of
whether it is an acceptable restriction (with ctfe maybe it is now).
import std.string;
enum s = "abcdefghijklmorpshtn";
static assert(s.length == 20);
enum t = s ~ s;
static assert(t.length == 40);
enum u = t ~ t;
static assert(u.length == 80);
enum v = u ~ u;
static assert(v.length == 160);
enum w = v ~ v;
static assert(w.length == 320);
enum x = w ~ v ~ s;
static assert(x.length == 500);
/*
// ok!
enum x = w ~ v ~ s[1..$];
static assert(x.length == 499);
*/
template iter(string s, T) {
static if(s.length == 0) {
enum iter = "";
}else{
enum iter = toUpper(s[0..1]) ~ iter!(s[1..$], T);
}
}
pragma(msg, iter!(x, int));
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 17:56:13 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 00:56:13 +0000 (UTC)
Subject: [Issue 10524] New: case and with() isn't work together
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10524
Summary: case and with() isn't work together
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: 4denizzz at gmail.com
--- Comment #0 from mimocrocodil <4denizzz at gmail.com> 2013-07-01 17:56:12 PDT ---
struct S
{
int field;
}
void main()
{
int a = 1;
S struct_with_long_name;
switch( a )
{
case 0:
struct_with_long_name.field = 444; // ok
break;
with( struct_with_long_name )
{
case 1:
field = 555; // segfault
break;
}
default:
break;
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 18:11:27 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 01:11:27 +0000 (UTC)
Subject: [Issue 7656] ddoc misinterprets commented parentheses in an example
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7656
--- Comment #3 from Kenji Hara 2013-07-01 18:11:26 PDT ---
(In reply to comment #1)
> https://github.com/D-Programming-Language/dmd/pull/1244
That was once merged, but was reverted so it had caused a regression:
https://github.com/D-Programming-Language/dmd/pull/1244#issuecomment-11162068
New pull request:
https://github.com/D-Programming-Language/dmd/pull/2287
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 18:11:44 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 01:11:44 +0000 (UTC)
Subject: [Issue 7715] DDoc eats $1, $2, $3 etc. inside d_code section
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7715
--- Comment #6 from Kenji Hara 2013-07-01 18:11:43 PDT ---
(In reply to comment #5)
> Sorry, it was reverted due to a regression
> (https://github.com/D-Programming-Language/dmd/pull/1244#issuecomment-11162068).
> Will work on it again soon.
New pull request:
https://github.com/D-Programming-Language/dmd/pull/2287
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 18:30:13 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 01:30:13 +0000 (UTC)
Subject: [Issue 4899] Ddoc: Warnings about stray parens do not include file
and line numbers for module comments
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=4899
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ddoc, pull
Platform|Other |All
OS/Version|Linux |All
--- Comment #5 from Kenji Hara 2013-07-01 18:30:07 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2291
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 19:04:08 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 02:04:08 +0000 (UTC)
Subject: [Issue 10462] interface thunk doesn't preserve EBX
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10462
--- Comment #4 from github-bugzilla at puremagic.com 2013-07-01 19:03:54 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/c331f2021404ecc75e8e62bd4d46b92de573008c
fix Issue 10462 - interface thunk doesn't preserve EBX
https://github.com/D-Programming-Language/dmd/commit/51efce6654e35a3ccb737fd7146acfda7dbf1210
Merge pull request #2278 from WalterBright/fix10462
fix Issue 10462 - interface thunk doesn't preserve EBX
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Mon Jul 1 21:36:49 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 04:36:49 +0000 (UTC)
Subject: [Issue 10462] interface thunk doesn't preserve EBX
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10462
--- Comment #5 from github-bugzilla at puremagic.com 2013-07-01 21:36:47 PDT ---
Commit pushed to dmd-1.x at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/ed1174fb43c6abc3baa94c80c711227fc7ab6830
Merge pull request #2278 from WalterBright/fix10462
fix Issue 10462 - interface thunk doesn't preserve EBX
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 00:29:43 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 07:29:43 +0000 (UTC)
Subject: [Issue 10491] Type inference for function arguments with default value
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10491
bearophile_hugs at eml.cc changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WONTFIX
--- Comment #5 from bearophile_hugs at eml.cc 2013-07-02 00:29:40 PDT ---
OK, closed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 00:33:40 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 07:33:40 +0000 (UTC)
Subject: [Issue 7227] [] syntax for empty associative array too?
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7227
--- Comment #5 from bearophile_hugs at eml.cc 2013-07-02 00:33:38 PDT ---
(In reply to comment #3)
> This patch has chosen the [] syntax over the [:] syntax.
But I prefer the [:] syntax, because it's more precise.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 00:44:00 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 07:44:00 +0000 (UTC)
Subject: [Issue 10475] destructor is called on 'for' loop variable even when
initialization failed
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10475
--- Comment #6 from github-bugzilla at puremagic.com 2013-07-02 00:43:41 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/6c7d77f690f509255950321e3e0fec9f29d02df6
fix Issue 10475 - destructor is called on 'for' loop variable even when
initialization failed
https://github.com/D-Programming-Language/dmd/commit/aaf64112624abab1f6cc8f610223f6e12b525e09
Merge pull request #2286 from 9rnsr/fix10475
Issue 10475 - destructor is called on 'for' loop variable even when
initialization failed
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 00:46:40 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 07:46:40 +0000 (UTC)
Subject: [Issue 7227] [] syntax for empty associative array too?
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7227
--- Comment #6 from bearophile_hugs at eml.cc 2013-07-02 00:46:28 PDT ---
Having two obvious syntaxes to do the same thing is not so good. So I suggest
to also introduce a warning for the usage of "null" as associative array
literal:
void foo(int[int]) {}
void main() {
foo(null);
int[int][] aas = [null];
aas[0] = [1: 2, 2: 3];
}
=>
test.d(3): Warning: explicit [:] empty associative array literal is better than
null, that will be deprecated
test.d(4): Warning: explicit [:] empty associative array literal is better than
null, that will be deprecated
(The wording of such warning message is modelled on another warning message:
test.d(3): Warning: explicit element-wise assignment (a)[] = 2 is better than a
= 2)
(This warning is not meant to be kept. Later this warning is meant to become a
deprecation, and later an error).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 01:01:59 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 08:01:59 +0000 (UTC)
Subject: [Issue 10320] Warning for old-style operator overloading methods
definition
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10320
--- Comment #1 from bearophile_hugs at eml.cc 2013-07-02 01:01:58 PDT ---
Cases like in this thread show that it's important to give a warning now:
http://forum.dlang.org/thread/hwfzaysrfxiiumppxwkt at forum.dlang.org
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 02:01:39 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 09:01:39 +0000 (UTC)
Subject: [Issue 5207] Immutability is broken in constructors
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=5207
--- Comment #3 from Lars T. Kyllingstad 2013-07-02 02:01:08 PDT ---
I'm not suggesting that the assignment be prohibited. Rather, I think it
should be illegal to *access* the variable before it is initialised.
If the current behaviour is by design, consider this an enhancement request.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 02:06:33 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 09:06:33 +0000 (UTC)
Subject: [Issue 10525] New: Struct as key in Associative array ignores value
semantics
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10525
Summary: Struct as key in Associative array ignores value
semantics
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: michal.minich at gmail.com
--- Comment #0 from Michal Minich 2013-07-02 02:06:31 PDT ---
DMD 2.063.2
struct S { char[] str; }
void main ()
{
auto s1 = S(cast(char[])"abc");
auto s2 = S(cast(char[])"Xbc");
// indirect members in structs are compared by value
assert (s1 != s2); // ok, structs are compared not equal
s2.str[0] = 'a';
assert (s1 == s2); // ok, structs are compared equal
// not so in AA
auto aa = [s1 : 1];
auto s1aa = s1 in aa;
assert (s1aa);
auto s2aa = s2 in aa;
assert (s2aa); // fails, but should pass
// s2 should be found in aa the same way as s1
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 04:27:29 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 11:27:29 +0000 (UTC)
Subject: [Issue 9857] UFCS for struct opCall
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=9857
--- Comment #14 from bearophile_hugs at eml.cc 2013-07-02 04:27:25 PDT ---
For potential downsides see also:
http://forum.dlang.org/thread/sdffgyosxmfjjjrshajy at forum.dlang.org
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 04:51:44 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 11:51:44 +0000 (UTC)
Subject: [Issue 10320] Warning for old-style operator overloading methods
definition
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10320
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra at gmail.com
See Also| |http://d.puremagic.com/issu
| |es/show_bug.cgi?id=9257
--- Comment #2 from monarchdodra at gmail.com 2013-07-02 04:51:42 PDT ---
(In reply to comment #1)
> Cases like in this thread show that it's important to give a warning now:
>
> http://forum.dlang.org/thread/hwfzaysrfxiiumppxwkt at forum.dlang.org
Related (but not duplicate) is also Issue 9257 - [ER] New optional "operator"
keyword to validate magic functions
http://d.puremagic.com/issues/show_bug.cgi?id=9257
And associated discussion:
http://forum.dlang.org/thread/iubdngjksicwxugrqesc at forum.dlang.org
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 05:10:38 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 12:10:38 +0000 (UTC)
Subject: [Issue 4899] Ddoc: Warnings about stray parens do not include file
and line numbers for module comments
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=4899
--- Comment #6 from github-bugzilla at puremagic.com 2013-07-02 05:10:36 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/328969f671c9fcdc2fb7b9ba7ae65e483074961d
fix Issue 4899 - Ddoc: Warnings about stray parens do not include file and line
numbers for module comments
Add ModuleDeclaration::loc and use it for "Stray paren" ddoc warning.
https://github.com/D-Programming-Language/dmd/commit/23c3c6add8162693f85b3b41c9bf6550a71a57d3
Merge pull request #2291 from 9rnsr/fix4899
Issue 4899 - Ddoc: Warnings about stray parens do not include file and line
numbers for module comments
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 05:10:57 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 12:10:57 +0000 (UTC)
Subject: [Issue 4899] Ddoc: Warnings about stray parens do not include file
and line numbers for module comments
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=4899
Andrej Mitrovic changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |andrej.mitrovich at gmail.com
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 07:05:17 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 14:05:17 +0000 (UTC)
Subject: [Issue 8563] Exception segfault
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=8563
--- Comment #6 from Kenji Hara 2013-07-02 07:05:14 PDT ---
I posted bug 10475 fix and now it's merged in git head.
Could you please confirm the actual case by using git head?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 07:25:07 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 14:25:07 +0000 (UTC)
Subject: [Issue 10482] Regression (2.063): Compiler doesn't warn about prefix
const
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10482
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|regression |enhancement
--- Comment #7 from Kenji Hara 2013-07-02 07:25:01 PDT ---
This is an intended change comes from issue 10150, so is not a regression.
Today dmd never distinguishes prefix storage class and scopes/labeled ones.
That's a design decision which sometimes talked by Walter.
But also, I can agree that it is a little bug-prone behavior.
So I switch this into enhancement issue.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 08:07:12 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 15:07:12 +0000 (UTC)
Subject: [Issue 10254] Purity correctness is broken with constructor
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10254
--- Comment #5 from github-bugzilla at puremagic.com 2013-07-02 08:07:10 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/6e6310d20dfa75c1d56b33be66056e9554092e0c
fix Issue 10254 - Purity correctness is broken with constructor
https://github.com/D-Programming-Language/dmd/commit/64e05bb8862c1cd33d61900957dc128d1c8d4712
Merge pull request #2135 from 9rnsr/fix10254
Issue 10254 - Purity correctness is broken with constructor
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 08:39:36 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 15:39:36 +0000 (UTC)
Subject: [Issue 10254] Purity correctness is broken with constructor
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10254
yebblies changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |yebblies at gmail.com
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 08:43:43 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 15:43:43 +0000 (UTC)
Subject: [Issue 10482] Regression (2.063): Compiler doesn't warn about prefix
const
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10482
--- Comment #8 from Dicebot 2013-07-02 08:43:42 PDT ---
(In reply to comment #7)
> This is an intended change comes from issue 10150, so is not a regression.
>
> Today dmd never distinguishes prefix storage class and scopes/labeled ones.
> That's a design decision which sometimes talked by Walter.
>
> But also, I can agree that it is a little bug-prone behavior.
> So I switch this into enhancement issue.
Yep, it is not a regression but a breaking change introduces by 10150, which
should not have been implemented in the first place. I wish I have noticed that
pull request before it was merged. There is currently minor discussion on topic
in 10150 thread.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 09:25:33 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 16:25:33 +0000 (UTC)
Subject: [Issue 6646] [SafeD] array.reserve is not @safe/trusted
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6646
--- Comment #3 from hsteoh at quickfur.ath.cx 2013-07-02 09:25:32 PDT ---
https://github.com/D-Programming-Language/druntime/pull/536
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 09:35:05 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 16:35:05 +0000 (UTC)
Subject: [Issue 6651] [SafeD] Exception/Throwable constructors are not @safe ?
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6651
hsteoh at quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |hsteoh at quickfur.ath.cx
Resolution| |WORKSFORME
--- Comment #1 from hsteoh at quickfur.ath.cx 2013-07-02 09:35:05 PDT ---
This bug seems no longer present in git HEAD. Please reopen if there's still a
problem.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 09:38:18 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 16:38:18 +0000 (UTC)
Subject: [Issue 7051] Class member with un-@safe destructor gives confusing
error
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7051
hsteoh at quickfur.ath.cx changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |hsteoh at quickfur.ath.cx
--- Comment #4 from hsteoh at quickfur.ath.cx 2013-07-02 09:38:17 PDT ---
The error message has improved in git HEAD:
/tmp/test.d(6): Error: safe function 'test.Bar.~this' cannot call system
function 'test.Foo.~this'
Should this issue be resolved?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 09:39:37 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 16:39:37 +0000 (UTC)
Subject: [Issue 7051] Class member with un-@safe destructor gives confusing
error
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7051
David Nadlinger changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 10:00:45 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 17:00:45 +0000 (UTC)
Subject: [Issue 7863] randomShuffle doesn't work with a Xorshift
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7863
Joseph Rushton Wakeling changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joseph.wakeling at webdrake.ne
| |t
--- Comment #1 from Joseph Rushton Wakeling 2013-07-02 10:00:43 PDT ---
Cf. my response to Issue #9607 -- there's a pull request under review that
should fix this: http://d.puremagic.com/issues/show_bug.cgi?id=9607
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 10:12:26 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 17:12:26 +0000 (UTC)
Subject: [Issue 8563] Exception segfault
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=8563
Maxim Fomin changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #7 from Maxim Fomin 2013-07-02 10:12:24 PDT ---
(In reply to comment #6)
> I posted bug 10475 fix and now it's merged in git head.
> Could you please confirm the actual case by using git head?
This issue is also fixed. Thank you.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 12:28:41 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 19:28:41 +0000 (UTC)
Subject: [Issue 6646] [SafeD] array.reserve is not @safe/trusted
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6646
--- Comment #4 from github-bugzilla at puremagic.com 2013-07-02 12:28:37 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/druntime
https://github.com/D-Programming-Language/druntime/commit/032bac64ef3e354da65da38314c51af09eebcf05
Fix issue 6646: array.reserve should be callable from SafeD.
https://github.com/D-Programming-Language/druntime/commit/fa85c1b413cbe81416f02995cfefe6107a4cbb4e
Merge pull request #536 from quickfur/issue6646
Fix issue 6646: array.reserve should be callable from SafeD.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 12:29:33 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 19:29:33 +0000 (UTC)
Subject: [Issue 6646] [SafeD] array.reserve is not @safe/trusted
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6646
Alex R?nne Petersen changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |alex at lycus.org
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 13:04:51 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 20:04:51 +0000 (UTC)
Subject: [Issue 10491] Type inference for function arguments with default value
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10491
--- Comment #6 from Henning Pohl 2013-07-02 13:04:46 PDT ---
(In reply to comment #4)
> (In reply to comment #1)
> > https://github.com/D-Programming-Language/dmd/pull/2270
>
> I think a decision should be taken. What do you think about this issue Henning
> Pohl?
Can only three people actually take decisions like that?
Let me comment on Kenji's four points:
1. True, but these little syntactic improvements make writing D more fun as a
whole.
2. This is what D should do more often.
3. The cost of inferring things. If the quality of the error messages are
appropriate, it is totally worth it.
4. In which way do "in ref" and "auto ref" conflict with this?
Walter has underlined multiple times the importance of beautiful code. And that
is the goal of this enhancement.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 14:00:25 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Tue, 2 Jul 2013 21:00:25 +0000 (UTC)
Subject: [Issue 10491] Type inference for function arguments with default value
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10491
--- Comment #7 from bearophile_hugs at eml.cc 2013-07-02 14:00:23 PDT ---
(In reply to comment #6)
> Can only three people actually take decisions like that?
I'd like Walter and/or Andrei to give a comment to this (and to your patch).
I have asked here, in the main D newsgroup, and your patch was exposed in
GitHub for several days.
> 1. True, but these little syntactic improvements make writing D more fun as a
> whole.
Default arguments are not so common...
> 3. The cost of inferring things. If the quality of the error messages are
> appropriate, it is totally worth it.
The point 3 by Hara is probably the most important. If he says this enhancement
may cause more typing problems then we should listen to him. At minimum your
patch should contain more tests. (But adding tests to a patch is receiving a
cold interest risks being a further waste of time.)
Thank you for your patch and your comments.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 19:08:50 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 02:08:50 +0000 (UTC)
Subject: [Issue 10518] Static SIMD vector constants cannot be defined.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10518
Henning Pohl changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |henning at still-hidden.de
Resolution| |DUPLICATE
--- Comment #1 from Henning Pohl 2013-07-02 19:08:49 PDT ---
*** This issue has been marked as a duplicate of issue 10312 ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 19:08:51 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 02:08:51 +0000 (UTC)
Subject: [Issue 10312] compiler assert failure with ctfe on simd vector type
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10312
Henning Pohl changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |Marco.Leise at gmx.de
--- Comment #5 from Henning Pohl 2013-07-02 19:08:49 PDT ---
*** Issue 10518 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: -------
From d-bugmail at puremagic.com Tue Jul 2 19:27:22 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 02:27:22 +0000 (UTC)
Subject: [Issue 10526] New: opDispatch with IFTI should not disable UFCS
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10526
Summary: opDispatch with IFTI should not disable UFCS
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: k.hara.pg at gmail.com
--- Comment #0 from Kenji Hara 2013-07-02 19:27:17 PDT ---
From: http://forum.dlang.org/post/cxgefmgjnzgoizrdtcbb at forum.dlang.org
In following code, opDispatch call requires IFTI due to TemplateTupleParameter
T deduction. However it unexpectedly disables UFCS.
import std.conv, std.stdio, std.algorithm;
struct S
{
void opDispatch(string s, T...)(T t)
if (s.startsWith("foo"))
{
writeln(s);
}
}
void main()
{
S s;
s.foo();
// --> OK
auto p = s.to!string();
// --> Error: s.opDispatch!("to") isn't a template
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 20:42:51 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 03:42:51 +0000 (UTC)
Subject: [Issue 10526] opDispatch with IFTI should not disable UFCS
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10526
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
--- Comment #1 from Kenji Hara 2013-07-02 20:42:47 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2292
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 20:55:58 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 03:55:58 +0000 (UTC)
Subject: [Issue 10517] readln(Char)(Char[] buf) accepts non-mutable buffers
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10517
--- Comment #2 from github-bugzilla at puremagic.com 2013-07-02 20:55:54 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos
https://github.com/D-Programming-Language/phobos/commit/97cec336a14c5d433970b930906bfeb68fdccaf3
Fix Issue 10517 - readln(Char)(Char[] buf) accepts non-mutable buffers
Also templatizes a global readln
https://github.com/D-Programming-Language/phobos/commit/3be7a03168c8763a4fef9d62210899d8a9be518c
Merge pull request #1381 from monarchdodra/readln
Fix Issue 10517 - readln(Char)(Char[] buf) accepts non-mutable buffers
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Tue Jul 2 21:00:32 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 04:00:32 +0000 (UTC)
Subject: [Issue 10517] readln(Char)(Char[] buf) accepts non-mutable buffers
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10517
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 03:51:22 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 10:51:22 +0000 (UTC)
Subject: [Issue 10527] New: Eliding more postblit constructor calls
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10527
Summary: Eliding more postblit constructor calls
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: tommitissari at hotmail.com
--- Comment #0 from Tommi 2013-07-03 03:51:18 PDT ---
Definitions:
1) 'Str' is a struct type which has a postblit constructor
2) 'var' is a variable whose unqualified type is Str
3) 'cpy' is a copy of the variable var
Proposed language change:
Whenever a copy is made from var to cpy (either by making a new variable or by
passing var to a function by value) and the compiler can determine (either
through analysing code or by deduction from a function signature) that during
the lifetime of cpy, no mutation is done to var nor to any data reachable from
it, the language should guarantee these two things:
1) cpy's postblit constructor is omitted when cpy is constructed
2) cpy's destructor is omitted when cpy goes out of scope
Examples:
Here are some examples, where the compiler can deduce that it's safe to omit
the postblit and destructor of cpy by merely looking at the function signature:
1)
int foo(T, U)(const Str cpy, const T t, immutable U u) pure { }
2)
void foo(T, U)(immutable Str cpy, T t, U u) { }
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 04:12:00 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 11:12:00 +0000 (UTC)
Subject: [Issue 10527] Eliding more postblit constructor calls
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10527
--- Comment #1 from Tommi 2013-07-03 04:12:00 PDT ---
(In reply to comment #0)
> [..] the language should guarantee these two things:
> 1) cpy's postblit constructor is omitted when cpy is constructed
> 2) cpy's destructor is omitted when cpy goes out of scope
Let's change this proposal so that the language would guarantee to do those
optimisations only when it can deduce that it can be done from looking at
function signatures. And the compiler can choose whether or not it wants to try
to do more postblit/destructor elisions through static analysis.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 06:55:57 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 13:55:57 +0000 (UTC)
Subject: [Issue 10527] Eliding more postblit constructor calls
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10527
--- Comment #2 from Tommi 2013-07-03 06:55:55 PDT ---
(In reply to comment #0)
> 2) 'var' is a variable whose unqualified type is Str
By this I mean:
is(std.traits.Unqual!(typeof(var)) == Str)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 07:33:40 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 14:33:40 +0000 (UTC)
Subject: [Issue 10463] dirEntries() segfaults on paths the user does not have
access to
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10463
Nils changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--- Comment #2 from Nils 2013-07-03 07:33:37 PDT ---
Issue 8563 is fixed. The test case of this issue now throws a nice "Permission
denied" exception. Closing.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 08:21:37 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 15:21:37 +0000 (UTC)
Subject: [Issue 10528] New: Private constant (enum) properties not private
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10528
Summary: Private constant (enum) properties not private
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: anoneuron at gmail.com
--- Comment #0 from anoneuron at gmail.com 2013-07-03 08:21:34 PDT ---
Manifest constants don't seem to honour the 'private' attribute when inside
aggregate type definitions. Here's an example:
/* --- module1.d --- */
private enum string ModuleData = "asdfgh";
struct Structure {
static private enum string Data = "qwerty";
};
/* --- module2.d --- */
import module1;
import std.stdio;
void main() {
writeln(ModuleData); // Error: mod1.ModuleData is private (correct)
writeln(Structure.Data); // no error (incorrect)
};
I can't find any reason why this might be permitted, so it seems like a bug to
me.
Tested using DMD v2.063.2 on WinXP.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 09:05:20 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 16:05:20 +0000 (UTC)
Subject: [Issue 9857] UFCS for struct opCall
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=9857
timon.gehr at gmx.ch changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |timon.gehr at gmx.ch
--- Comment #15 from timon.gehr at gmx.ch 2013-07-03 09:05:16 PDT ---
The discussion is misguided. opCall is compatible with UFCS already. I suggest
to close this down and to open a more detailed enhancement request for using
local symbols with UFCS instead if that is desired.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 09:22:37 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 16:22:37 +0000 (UTC)
Subject: [Issue 10529] New: rmdirRecurse should have an optional force
parameter for read-only file removal
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10529
Summary: rmdirRecurse should have an optional force parameter
for read-only file removal
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nobody at puremagic.com
ReportedBy: andrej.mitrovich at gmail.com
--- Comment #0 from Andrej Mitrovic 2013-07-03 09:22:37 PDT ---
On win32 rmdirRecurse will fail if a file in the directory has the read-only
attribute set. The win32 API says such a file needs to have its read-only
attribute removed, however Phobos lacks a 'setFileAttributes' function.
I propose we add an optional 'force' enum or boolean to rmdirRecurse, which
will force removal of read-only files by removing the read-only attribute.
This probably means other related functions like 'remove' will need to have
this optional parameter.
Additionally we should provide a setAttributes function
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 09:42:19 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 16:42:19 +0000 (UTC)
Subject: [Issue 9857] UFCS for struct opCall
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=9857
bearophile_hugs at eml.cc changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |WORKSFORME
--- Comment #16 from bearophile_hugs at eml.cc 2013-07-03 09:42:17 PDT ---
(In reply to comment #15)
> The discussion is misguided. opCall is compatible with UFCS already.
Right, I didn't realize this works:
struct Foo {
int opCall(bool b) {
return 0;
}
}
Foo foo;
void main() {
auto b1 = foo(true); // OK
auto b2 = true.foo; // Error
}
> I suggest to close this down
OK, closed.
> and to open a more detailed enhancement request for using
> local symbols with UFCS instead if that is desired.
That's a quite different need. It needs more thinking. Thank you for the note.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 09:48:02 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 16:48:02 +0000 (UTC)
Subject: [Issue 10530] New: Initializers inside named enum declarations cannot
forward reference other members
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10530
Summary: Initializers inside named enum declarations cannot
forward reference other members
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: timon.gehr at gmx.ch
--- Comment #0 from timon.gehr at gmx.ch 2013-07-03 09:48:00 PDT ---
DMD 2.063/git head:
enum X {foo=0, bar=foo} // ok
enum Y {foo=bar, bar=0} // error
Both lines should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 09:57:21 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 16:57:21 +0000 (UTC)
Subject: [Issue 7227] [:] as empty associative array literal,
plus warning for null
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7227
bearophile_hugs at eml.cc changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[:] as empty associative |[:] as empty associative
|array literal |array literal, plus warning
| |for null
--- Comment #7 from bearophile_hugs at eml.cc 2013-07-03 09:57:18 PDT ---
I have opened a discussion here:
http://forum.dlang.org/thread/rkdzdxygpflpnaznxxnl at forum.dlang.org
In the discussion I have explained better why I think [:] is better than [].
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 10:17:40 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 17:17:40 +0000 (UTC)
Subject: [Issue 953] Multiple C style declarations of same type cannot be in
one statement
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=953
bearophile_hugs at eml.cc changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bearophile_hugs at eml.cc
--- Comment #7 from bearophile_hugs at eml.cc 2013-07-03 10:17:37 PDT ---
So this code has different meanings in C and D:
void main() {
int *a, b;
}
And to keep the D language simple this is disallowed:
int a[8], c[8];
Then what is this issue asking for?
In Issue 5807 I have suggested to disallow mixing C and D style of array in a
single declaration:
// array of 5 dynamic arrays of ints.
int[][5] c;
int[] c[5];
int c[5][];
Also because of some problems it causes with vector ops syntax:
void main() {
int[] a1 = [1, 2, 3];
int[] a2 = new int[3];
a2[] = a1[]; // OK
int[3] a3[] = a2[]; // line 5, Error
}
Beside disallowing the mix of C and D syntaxes in a single declaration, another
thing that may be good to do is to perpetually deprecate the C syntax (and do
not turn it into an error).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 10:34:48 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 17:34:48 +0000 (UTC)
Subject: [Issue 10531] New: Enum base type not inferred from initializer of
first member
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10531
Summary: Enum base type not inferred from initializer of first
member
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: timon.gehr at gmx.ch
--- Comment #0 from timon.gehr at gmx.ch 2013-07-03 10:34:47 PDT ---
http://dlang.org/enum.html states:
If the EnumBaseType is not explicitly set, and the first EnumMember has an
initializer, it is set to the type of that initializer. Otherwise, it defaults
to type int.
However:
enum E{x=""}
Error: cannot implicitly convert expression ("") of type string to int
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 10:43:07 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 17:43:07 +0000 (UTC)
Subject: [Issue 10531] Enum base type not inferred from initializer of first
member
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10531
Andrej Mitrovic changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |andrej.mitrovich at gmail.com
Resolution| |DUPLICATE
--- Comment #1 from Andrej Mitrovic 2013-07-03 10:43:05 PDT ---
This was fixed in git-head recently.
*** This issue has been marked as a duplicate of issue 3096 ***
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 10:43:09 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 17:43:09 +0000 (UTC)
Subject: [Issue 3096] EnumBaseType
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=3096
Andrej Mitrovic changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |timon.gehr at gmx.ch
--- Comment #4 from Andrej Mitrovic 2013-07-03 10:43:06 PDT ---
*** Issue 10531 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: -------
From d-bugmail at puremagic.com Wed Jul 3 11:19:36 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 18:19:36 +0000 (UTC)
Subject: [Issue 5788] Return [] array
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=5788
--- Comment #3 from bearophile_hugs at eml.cc 2013-07-03 11:19:34 PDT ---
currently this code:
void main() {
int[] emptyArray = [];
}
Produces:
__Dmain comdat
L0: push EAX
mov EAX,offset FLAT:_D11TypeInfo_Ai6__initZ
push 0
push EAX
call near ptr __d_arrayliteralTX
add ESP,8
xor EAX,EAX
pop ECX
ret
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 13:24:08 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 20:24:08 +0000 (UTC)
Subject: [Issue 10530] Initializers inside named enum declarations cannot
forward reference other members
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10530
--- Comment #1 from timon.gehr at gmx.ch 2013-07-03 13:24:07 PDT ---
Actually it might be fine for the second line to be in error, since the
compiler cannot easily figure out the enum base type in the general case when
such a constellation is present.
This should certainly work though:
enum Y : int {foo=bar, bar=0}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 13:46:51 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Wed, 3 Jul 2013 20:46:51 +0000 (UTC)
Subject: [Issue 10530] Initializers inside named enum declarations cannot
forward reference other members
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10530
Andrej Mitrovic changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |andrej.mitrovich at gmail.com
--- Comment #2 from Andrej Mitrovic 2013-07-03 13:46:36 PDT ---
However this shouldn't work:
enum Y : int {foo=bar, bar}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 18:34:27 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 01:34:27 +0000 (UTC)
Subject: [Issue 10532] New: Silence some unreachable statement warnings when
in a static foreach
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10532
Summary: Silence some unreachable statement warnings when in a
static foreach
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: andrej.mitrovich at gmail.com
--- Comment #0 from Andrej Mitrovic 2013-07-03 18:34:26 PDT ---
-----
import std.traits;
enum E { a, b}
void main()
{
foreach (e; EnumMembers!E)
{
if (e == E.a)
continue;
// lots of code follows..
auto x = 1;
}
}
-----
$ dmd -w test.d
> test.d(14): Warning: statement is not reachable
I don't know if this is doable, but it's a little annoying that we have these
unreachable statement warnings when in a static foreach loop. It forces use to
use an else statement, but this introduces indentation.
In this specific test-case the alternative could be to Filter!() through the
EnumMembers so "E.a" never appears in the loop, but for more complex cases such
filtering may not be usable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 18:59:29 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 01:59:29 +0000 (UTC)
Subject: [Issue 10533] New: Bad diagnostic when template has alias overloads
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10533
Summary: Bad diagnostic when template has alias overloads
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: andrej.mitrovich at gmail.com
--- Comment #0 from Andrej Mitrovic 2013-07-03 18:59:28 PDT ---
-----
struct S1
{
T get(T)() if (is(T == float)) { }
}
struct S2
{
auto get(alias value)()
{
return S1.get!(typeof(value));
}
}
struct S3
{
auto get(alias value)()
{
return get!(typeof(value));
}
T get(T)() if (is(T == float))
{
return T.init;
}
}
void main()
{
// Error: template instance get!int does not match template declaration
get(T)() if (is(T == float))
S1.get!int;
// Error: template instance get!int does not match template declaration
get(T)() if (is(T == float))
S2.get!1;
// Error: cannot resolve type for this.get!int
S3.get!1;
}
-----
Observations:
S2.get calls into S1.get, and creates a nice error message. However in S3 the
get templates are overloaded against each other, and this causes the diagnostic
to become bad. S3.get should have the same diagnostic as S2.get.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 19:01:40 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 02:01:40 +0000 (UTC)
Subject: [Issue 10534] New: Addition and subtraction of delegates allowed
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10534
Summary: Addition and subtraction of delegates allowed
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: callumenator at gmail.com
--- Comment #0 from callumenator at gmail.com 2013-07-03 19:01:39 PDT ---
DMD 2.063
void main()
{
int delegate() a = ()=>5;
int delegate() b = ()=>5;
auto c1 = a+b; // passes (and will crash if c1() called)
auto c2 = a-b; // passes (and will crash if c2() called)
auto c3 = a/b; // a & b not of arithmetic type
auto c4 = a*b; // a & b not of arithmetic type
}
DMD properly rejects all arithmetic if delegates are typed as int function()'s.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 20:47:18 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 03:47:18 +0000 (UTC)
Subject: [Issue 10534] Addition and subtraction of delegates allowed
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10534
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
--- Comment #1 from Kenji Hara 2013-07-03 20:47:05 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2294
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 22:18:32 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 05:18:32 +0000 (UTC)
Subject: [Issue 10535] New: Add a function to druntime which returns an empty
AA
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10535
Summary: Add a function to druntime which returns an empty AA
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nobody at puremagic.com
ReportedBy: jmdavisProg at gmx.com
--- Comment #0 from Jonathan M Davis 2013-07-03 22:18:30 PDT ---
Right now, the only way to get an empty AA (as opposed to a null one) is to add
an element to it and then remove it, which is neither user-friendly, nor
efficient. It would be easy enough to create a function which at least wrapped
all that (creating the AA, adding the element, and then removing it), but it
would be more efficient if the AA implementation did it, since it should be
able to do it without having to add or remove an element. It would also be
possible for the AA implementation to do it without using the init property (as
adding and then removing an element would likely require the init property in
order to get an element to add).
So, this enhancement request is for adding a function to druntime which returns
an empty AA without actually adding or removing elements from the AA to do it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Wed Jul 3 22:40:24 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 05:40:24 +0000 (UTC)
Subject: [Issue 10535] Add a function to druntime which returns an empty AA
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10535
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra at gmail.com
--- Comment #1 from monarchdodra at gmail.com 2013-07-03 22:40:22 PDT ---
Not to hijack this, but before we add that AA specific function, we should take
into account that a LOT of other objects require this. Basically, every
reference semantic object in Phobos: Containers, Appender, PRNGs...
There might be a better "generic" solution to the "empty initialization" (eg:
"arg-less-constructor") problem.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 00:47:35 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 07:47:35 +0000 (UTC)
Subject: [Issue 10536] New: std.typecons.wrap doesn't work with a class that
defines opCast
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10536
Summary: std.typecons.wrap doesn't work with a class that
defines opCast
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nobody at puremagic.com
ReportedBy: k.hara.pg at gmail.com
--- Comment #0 from Kenji Hara 2013-07-04 00:47:34 PDT ---
std.typecons.wrap and unwrap internally uses cross-cast, but current
implementation accidentally takes opCast member functions.
Code:
----
import std.typecons;
interface Interface { int foo(); }
class Pluggable {
int foo() { return 1; }
@disable void opCast(T, this X)(); // !
}
void main() {
Interface i = new Pluggable().wrap!Interface;
assert(i.foo() == 1);
}
Output:
----
std\typecons.d(2780): Error: function test.Pluggable.opCast!(inout(Object),
inout(Pluggable)).opCast is not callable because it is annotated with @disable
std\typecons.d(2780): Error: pure function
'std.typecons.wrap!(Interface).wrap!(Pluggable).Impl._wrap_getSource' cannot
call impure function 'test.Pluggable.opCast!(inout(Object),
inout(Pluggable)).opCast'
std\typecons.d(2780): Error: cannot implicitly convert expression
(this._wrap_source.opCast()) of type void to inout(Object)
test.d(16): Error: template instance
std.typecons.wrap!(Interface).wrap!(Pluggable) error instantiating
----
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 00:48:37 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 07:48:37 +0000 (UTC)
Subject: [Issue 10537] New: Forward reference error on 'yield' toy example.
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10537
Summary: Forward reference error on 'yield' toy example.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: timon.gehr at gmx.ch
--- Comment #0 from timon.gehr at gmx.ch 2013-07-04 00:48:36 PDT ---
Compiled and ran with DMD 2.060, does not compile anymore with DMD 2.063:
http://dpaste.dzfl.pl/baa538af
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 00:51:57 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 07:51:57 +0000 (UTC)
Subject: [Issue 10538] New: std.typecons.wrap should consider opDispatch
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10538
Summary: std.typecons.wrap should consider opDispatch
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nobody at puremagic.com
ReportedBy: k.hara.pg at gmail.com
--- Comment #0 from Kenji Hara 2013-07-04 00:51:56 PDT ---
This code currently doesn't work, but it should.
import std.typecons;
interface Interface
{
int foo();
int bar(int);
}
class Pluggable
{
int opDispatch(string name, A...)(A args) { return 100; }
}
void main()
{
Interface i = wrap!Interface(new Pluggable());
assert(i.foo() == 100);
assert(i.bar(10) == 100);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 01:10:19 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 08:10:19 +0000 (UTC)
Subject: [Issue 10536] std.typecons.wrap doesn't work with a class that
defines opCast
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10536
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
--- Comment #1 from Kenji Hara 2013-07-04 01:10:18 PDT ---
https://github.com/D-Programming-Language/phobos/pull/1386
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 01:10:24 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 08:10:24 +0000 (UTC)
Subject: [Issue 10538] std.typecons.wrap should consider opDispatch
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10538
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
--- Comment #1 from Kenji Hara 2013-07-04 01:10:23 PDT ---
https://github.com/D-Programming-Language/phobos/pull/1386
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 01:14:16 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 08:14:16 +0000 (UTC)
Subject: [Issue 10243] [CTFE] Wrong-code on passing dereferenced array pointer
by ref
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10243
--- Comment #3 from Don 2013-07-04 01:14:14 PDT ---
The original test case in this bug report works for me now, and your comment
"// now works" indicates that it is fixed for you as well?
The code in comment 2 is a different bug. Although the effects look very
similar, it is actually independent of the original one. The bug lies in a
different part of the code.
Generally, you should create a new bug report rather than reopening a bug, if
the test case in the original bug report has been fixed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 01:23:32 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 08:23:32 +0000 (UTC)
Subject: [Issue 10266] CTFE: Allow reinterpret casts T <-> T[1]
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10266
--- Comment #3 from Don 2013-07-04 01:23:30 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > I suspect that after the cast, it might not be a genuine array.
>
> I like the idea to not create genuine array here. Just a restricted array for
> e.g. `foreach`.
Hmmm, I don't know how to do that. This kind of feature is practically
guaranteed to fail, it creates dozens of weird special cases (and they would
all be subtle wrong-code bugs).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 01:37:17 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 08:37:17 +0000 (UTC)
Subject: [Issue 10314] Add std.traits.signed
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10314
--- Comment #2 from github-bugzilla at puremagic.com 2013-07-04 01:37:13 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/phobos
https://github.com/D-Programming-Language/phobos/commit/378fe783523259849beebcc7553c0a9654d0c4f9
Implement issue# 10314.
This moves std.traits.unsigned to std.conv and adds std.conv.signed,
since for some reason, we have std.traits.unsigned but do not have
std.traits.signed.
https://github.com/D-Programming-Language/phobos/commit/1b230c39c516e762a18a3a88748c52d4bfdc907a
Merge pull request #1341 from jmdavis/signed
Implement issue# 10314 (add std.traits.signed).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 01:38:05 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 08:38:05 +0000 (UTC)
Subject: [Issue 10314] Add std.traits.signed
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10314
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 01:39:37 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 08:39:37 +0000 (UTC)
Subject: [Issue 10539] New: [REG][2.063] Implicit pointer to array dereference
for .ptr property fails
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10539
Summary: [REG][2.063] Implicit pointer to array dereference for
.ptr property fails
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: monarchdodra at gmail.com
--- Comment #0 from monarchdodra at gmail.com 2013-07-04 01:39:36 PDT ---
-----------------------
void main()
{
int[2][2] a;
int* p1 = a.ptr.ptr; //error
int* p2 = (*a.ptr).ptr; //OK
}
-----------------------
2.063 and 2.063.2 produce:
Error: cannot resolve type for &(*& a)[0]
This used to work up to 2.062.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 01:56:44 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 08:56:44 +0000 (UTC)
Subject: [Issue 10528] Private constant (enum) properties not private
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10528
--- Comment #1 from Adrien Pensart 2013-07-04 01:56:36 PDT ---
Created an attachment (id=1228)
Testcase for visibility attribute bug
A simpler testcase, visibility attribute is completely broken, it could cause
big troubles...
tested on 2.063 on Windows XP, could someone test on other platforms ?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 02:09:59 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 09:09:59 +0000 (UTC)
Subject: [Issue 10539] [REG][2.063] Implicit pointer to array dereference for
.ptr property fails
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10539
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
Version|unspecified |D2
--- Comment #1 from Kenji Hara 2013-07-04 02:09:56 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2296
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 02:15:48 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 09:15:48 +0000 (UTC)
Subject: [Issue 10540] New: variable used before set for empty static arrays,
with -inline -O
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10540
Summary: variable used before set for empty static arrays, with
-inline -O
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: monarchdodra at gmail.com
--- Comment #0 from monarchdodra at gmail.com 2013-07-04 02:15:47 PDT ---
Thread:
http://forum.dlang.org/thread/khdhvzfdfljbtlyfqocw at forum.dlang.org#post-khdhvzfdfljbtlyfqocw:40forum.dlang.org
When compiled with -O -inline:
--------
struct S
{
int[0] a;
void do_it()
{
foo(a);
}
}
void foo(Args...)(Args args)
{
//foreach(arg; args)
// if (arg.ptr == null)
// return;
bar(args);
}
void bar(Args...)(Args args)
{
foreach(arg; args)
if (arg.ptr == null)
return;
}
void main()
{}
--------
Produces:
main.d(11): Error: variable _param_0 used before set
--------
Possibly the compiler optimizes out a's initialization, since it is an empty
static array.
Code is glitchy: Not only does the bug appear only in bar (and not foo),
un-commenting the code in foo will *fix* the call in bar...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 02:16:30 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 09:16:30 +0000 (UTC)
Subject: [Issue 10540] variable used before set for empty static arrays,
with -inline -O
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10540
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
URL| |http://forum.dlang.org/thre
| |ad/khdhvzfdfljbtlyfqocw at for
| |um.dlang.org
See Also| |http://d.puremagic.com/issu
| |es/show_bug.cgi?id=7953
--- Comment #1 from monarchdodra at gmail.com 2013-07-04 02:16:29 PDT ---
Possibly related:
http://d.puremagic.com/issues/show_bug.cgi?id=7953
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 03:03:55 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 10:03:55 +0000 (UTC)
Subject: [Issue 3646] Default values of function arguments are ignored when
instantiating a template.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=3646
--- Comment #12 from github-bugzilla at puremagic.com 2013-07-04 03:03:45 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/877e7bfd7c29fb016323934bb04bd3420bffe5c7
Default args and arg identifiers are now volatile information in TypeFunction.
1. The extra informations would be kept after semantic analysis for function
pointer and delegate types. But merging type would strip all the extras from
the type structure, then cache the stripped copy into.
2. The types has extra informations cannot be named. In other words,
AliasDeclaration would always strip the aliased type. This rule also works for
Template Type Parameter, and fixes issue 3646 well.
3. CondExp would strip them from the type of its result.
https://github.com/D-Programming-Language/dmd/commit/bce2d07d6cd2c09a5153afc65260b63c32447ade
fix Issue 3646 - Default values of function arguments are ignored when
instantiating a template.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 03:04:15 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 10:04:15 +0000 (UTC)
Subject: [Issue 3866] anonymous delegate with default parameters cross-talks
to another anonymous delegate
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=3866
--- Comment #14 from github-bugzilla at puremagic.com 2013-07-04 03:04:04 PDT ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/d7362898f16d7d5e04ac4e9f374a39a5e8e0ff53
Improved fix for Issue 3866 - anonymous delegate with default parameters
cross-talks to another anonymous delegate
This reverts commit acc22ce25db42facfe4917aeceabd28a410f4c95,
and moves original test into runnable/functype.d
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 03:09:17 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 10:09:17 +0000 (UTC)
Subject: [Issue 10541] New: Failure writing to elements of std.range.zip
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10541
Summary: Failure writing to elements of std.range.zip
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nobody at puremagic.com
ReportedBy: joseph.wakeling at webdrake.net
--- Comment #0 from Joseph Rushton Wakeling 2013-07-04 03:09:15 PDT ---
According to the documentation, std.range.zip "offers mutation and swapping if
all ranges offer it". However, as the attached code sample shows, attempting
to write to elements of a zip in a foreach loop consistently fail, even when
accessed by ref and when all ranges in the zip are mutable.
The sample code shows (i) foreach'ing over a lockstep of a non-mutable range
and an array, writing to the array; (ii) foreach'ing over a zip of a
non-mutable range and an array; (iii) foreach'ing over a zip of two arrays,
writing to the second, with only the elements of the second accessed via ref;
(iv) foreach'ing over a zip of two arrays, accessing the elements of both via
ref.
The foreach over the lockstep results in an array with correctly-written
values, but the arrays that should be written to via foreach over zip remain
full of nan's.
This problem is also a block to the proposal in #8155 to deprecate lockstep in
favour of zip, since it makes it impossible to do a blanket replace
's/lockstep/zip/' and have the resulting code work.
At a minimum, zip should be corrected to ensure that its elements are mutable
in line with the statement made in the docs (i.e., the 3rd and 4th cases in the
sample code should result in arrays filled with correct values). Ideally,
elements of a zip that come from a mutable range should themselves be mutable
even if the other ranges in the zip aren't (i.e. the 2nd case in the sample
code should also work).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 03:09:56 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 10:09:56 +0000 (UTC)
Subject: [Issue 10541] Failure writing to elements of std.range.zip
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10541
--- Comment #1 from Joseph Rushton Wakeling 2013-07-04 03:09:54 PDT ---
Created an attachment (id=1229)
Sample code to illustrate the problem.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 03:10:58 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 10:10:58 +0000 (UTC)
Subject: [Issue 8155] Deprecate std.range.lockstep
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=8155
--- Comment #17 from Joseph Rushton Wakeling 2013-07-04 03:10:53 PDT ---
(In reply to comment #16)
> If not already present I suggest you to open an enhancement request that asks
> for your improvement of zip, and then we'll make this issue dependant to the
> other one. They are two separate issues.
Done: Issue #10541.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 03:11:36 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 10:11:36 +0000 (UTC)
Subject: [Issue 10528] Private constant (enum) properties not private
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10528
Adrien Pensart changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |crunchengine at gmail.com
Severity|normal |major
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 04:42:57 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 11:42:57 +0000 (UTC)
Subject: [Issue 10528] Private constant (enum) properties not private
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10528
Henning Pohl changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |henning at still-hidden.de
Severity|major |normal
--- Comment #2 from Henning Pohl 2013-07-04 04:42:55 PDT ---
(In reply to comment #1)
> Created an attachment (id=1228) [details]
> Testcase for visibility attribute bug
>
> A simpler testcase, visibility attribute is completely broken, it could cause
> big troubles...
>
> tested on 2.063 on Windows XP, could someone test on other platforms ?
In D "private" and "protected" symbols are also accessible in the module they
are declared in. So your test case should compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 04:51:52 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 11:51:52 +0000 (UTC)
Subject: [Issue 3646] Default values of function arguments are ignored when
instantiating a template.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=3646
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Version|D1 & D2 |D2
Resolution| |FIXED
--- Comment #13 from Kenji Hara 2013-07-04 04:51:50 PDT ---
Right now, default argument is changed to not part of function type in D2.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 04:53:03 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 11:53:03 +0000 (UTC)
Subject: [Issue 3866] anonymous delegate with default parameters cross-talks
to another anonymous delegate
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=3866
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|REOPENED |RESOLVED
Version|D1 & D2 |D2
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 04:53:26 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 11:53:26 +0000 (UTC)
Subject: [Issue 8579] Default parameter appears a part of typeof().stringof of
a function variable
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=8579
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 04:54:28 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 11:54:28 +0000 (UTC)
Subject: [Issue 8579] Default parameter appears a part of typeof().stringof of
a function variable
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=8579
--- Comment #4 from Kenji Hara 2013-07-04 04:54:26 PDT ---
Fixed commit:
https://github.com/D-Programming-Language/dmd/commit/a711eb6b499ca85b7cfa4e758d9e968fef8d315f
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 05:55:39 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 12:55:39 +0000 (UTC)
Subject: [Issue 7780] Template mixin'd members do not properly overload
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7780
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull, rejects-valid
--- Comment #3 from Kenji Hara 2013-07-04 05:55:37 PDT ---
(In reply to comment #0)
[snip]
>
> foo.d(19): Error: __overloadset isn't a template
>
> Or (without the wrapping class):
>
> foo.d(17): Error: template instance C!(0) ambiguous template declaration
> foo.B!().C(int n : 1) and foo.A!().C(int n : 0)
>
> The two versions of C here introduced could clearly coexist and be referred to
> as Foo.C!0 and Foo.C!1.
https://github.com/D-Programming-Language/dmd/pull/1660
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 07:16:47 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 14:16:47 +0000 (UTC)
Subject: [Issue 9262] compilation of erroneous source files causes segfault in
Package
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=9262
Don changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice
Summary|compilation of erroneous |compilation of erroneous
|source files causes |source files causes
|segfault |segfault in Package
--- Comment #2 from Don 2013-07-04 07:16:46 PDT ---
This is crashing in Package::~Package(). I think this has already been fixed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 07:26:46 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 14:26:46 +0000 (UTC)
Subject: [Issue 10542] New: implicitly generated class ctor doesnt inherit
base class ctor attributes
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10542
Summary: implicitly generated class ctor doesnt inherit base
class ctor attributes
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: henning at still-hidden.de
--- Comment #0 from Henning Pohl 2013-07-04 07:26:45 PDT ---
class B
{
this() nothrow pure @safe { }
}
class D : B
{
}
void test() nothrow pure @safe
{
new M;
}
----
main.d(12): Error: pure function 'main.test' cannot call impure function
'main.D.this'
main.d(12): Error: safe function 'main.test' cannot call system function
'main.D.this'
main.d(12): Error: constructor this is not nothrow
main.d(10): Error: function 'main.test' is nothrow yet may throw
----
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 07:27:08 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 14:27:08 +0000 (UTC)
Subject: [Issue 10542] implicitly generated class ctor doesnt inherit base
class ctor attributes
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10542
--- Comment #1 from Henning Pohl 2013-07-04 07:27:07 PDT ---
s/M/D
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 07:33:00 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 14:33:00 +0000 (UTC)
Subject: [Issue 10542] implicitly generated class ctor doesnt inherit base
class ctor attributes
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10542
Henning Pohl changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull, rejects-valid
--- Comment #2 from Henning Pohl 2013-07-04 07:32:59 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2297
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 07:36:21 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 14:36:21 +0000 (UTC)
Subject: [Issue 7322] Taking address of deprecated functions isn't refused
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=7322
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull
--- Comment #9 from Kenji Hara 2013-07-04 07:36:18 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2130
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 09:30:33 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 16:30:33 +0000 (UTC)
Subject: [Issue 10543] New: std.algorithm.map incorrectly uses source range
length for narrow strings
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
Summary: std.algorithm.map incorrectly uses source range length
for narrow strings
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nobody at puremagic.com
ReportedBy: peter.alexander.au at gmail.com
--- Comment #0 from Peter Alexander 2013-07-04 09:30:32 PDT ---
void main()
{
import std.algorithm;
import std.stdio;
string s = "???????";
auto m = s.map!(a => 1);
writeln(m, ", ", m.length);
}
Gives:
[1, 1, 1, 1, 1, 1, 1], 21
Clearly the reported length (21) is wrong, it should be 7.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 09:31:55 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 16:31:55 +0000 (UTC)
Subject: [Issue 10543] std.algorithm.map incorrectly uses source range length
for narrow strings
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
--- Comment #1 from Peter Alexander 2013-07-04 09:31:54 PDT ---
(In reply to comment #0)
> Clearly the reported length (21) is wrong, it should be 7.
Scratch that. length shouldn't be available at all for narrow strings as it is
unobtainable in constant time.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 10:02:23 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 17:02:23 +0000 (UTC)
Subject: [Issue 10544] New: writeln!(inout(int)) does not work
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10544
Summary: writeln!(inout(int)) does not work
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: andrei at erdani.com
--- Comment #0 from Andrei Alexandrescu 2013-07-04 10:02:22 PDT ---
Refer to
http://stackoverflow.com/questions/17460065/how-to-print-inout-parameters for
details. In all likelihood Unqual is the culprit.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 10:10:12 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 17:10:12 +0000 (UTC)
Subject: [Issue 10542] implicitly generated class ctor doesnt inherit base
class ctor attributes
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10542
--- Comment #3 from github-bugzilla at puremagic.com 2013-07-04 10:10:10 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/6505a8d8affb22d4d6c9c2da465e26f1d5648016
fix issue 10542 - implicitly generated class ctor doesnt inherit base
class ctor attributes
https://github.com/D-Programming-Language/dmd/commit/9af380a868c5e63bcfa1dc7d2b184d9764b680e0
Merge pull request #2297 from hpohl/10542
fix issue 10542 - implicitly generated class ctor doesn't inherit base class
ctor attributes
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 10:10:22 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 17:10:22 +0000 (UTC)
Subject: [Issue 10542] implicitly generated class ctor doesnt inherit base
class ctor attributes
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10542
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 10:41:44 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 17:41:44 +0000 (UTC)
Subject: [Issue 10543] std.algorithm.map incorrectly uses source range length
for narrow strings
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
bearophile_hugs at eml.cc changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bearophile_hugs at eml.cc
--- Comment #2 from bearophile_hugs at eml.cc 2013-07-04 10:41:41 PDT ---
Where's the bug here?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 10:43:23 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 17:43:23 +0000 (UTC)
Subject: [Issue 10543] std.algorithm.map incorrectly uses source range length
for narrow strings
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
--- Comment #3 from Peter Alexander 2013-07-04 10:43:22 PDT ---
(In reply to comment #2)
> Where's the bug here?
It says the length of [1, 1, 1, 1, 1, 1, 1] is 21. It isn't. It's 7.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 10:47:57 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 17:47:57 +0000 (UTC)
Subject: [Issue 10543] std.algorithm.map incorrectly uses source range length
for narrow strings
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
9999 changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mailnew4ster at gmail.com
--- Comment #4 from 9999 2013-07-04 10:47:52 PDT ---
21 is the number of UTF-8 code units.
Using dstring produces 7.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 10:54:47 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 17:54:47 +0000 (UTC)
Subject: [Issue 10543] std.algorithm.map incorrectly uses source range length
for narrow strings
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
--- Comment #5 from Peter Alexander 2013-07-04 10:54:42 PDT ---
(In reply to comment #4)
> 21 is the number of UTF-8 code units.
> Using dstring produces 7.
I am not requesting the length of the string, I am requesting the length of the
map over the string. As ranges, strings are ranges of code points, not code
units, so the number of elements in the *map* (confirmed by the output) is
seven, i.e. that is the number of times you can safely call popFront on the
map.
I'm struggling to understand the confusion.
m is a range of seven integers
m.length is 21
walkLength(m) is also 21
This is completely broken.
I fully understand that narrow strings use length to report code units, not
code points, but m is not a string, so that distinction does not apply.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 12:57:13 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 19:57:13 +0000 (UTC)
Subject: [Issue 10543] std.algorithm.map incorrectly uses source range length
for narrow strings
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra at gmail.com
--- Comment #6 from monarchdodra at gmail.com 2013-07-04 12:51:16 PDT ---
(In reply to comment #5)
> I'm struggling to understand the confusion.
The problem is perfectly clear.
Are you already correcting this? If not, I'll take care of it.
I remember having seen this in one of my first pulls correcting map, but got
confused about the fact there is an *explicit* test to do things wrong... Time
to correct it for good I guess.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 13:15:11 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 20:15:11 +0000 (UTC)
Subject: [Issue 10543] std.algorithm.map incorrectly uses source range length
for narrow strings
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
--- Comment #7 from Peter Alexander 2013-07-04 13:15:10 PDT ---
(In reply to comment #6)
> (In reply to comment #5)
> > I'm struggling to understand the confusion.
>
> The problem is perfectly clear.
>
> Are you already correcting this? If not, I'll take care of it.
>
> I remember having seen this in one of my first pulls correcting map, but got
> confused about the fact there is an *explicit* test to do things wrong... Time
> to correct it for good I guess.
I'm not fixing it right now, go ahead.
I only noticed it when I looked at the source. No idea why it's explicitly
coded to be wrong...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 13:24:52 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 20:24:52 +0000 (UTC)
Subject: [Issue 10539] [REG][2.063] Implicit pointer to array dereference for
.ptr property fails
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10539
--- Comment #2 from github-bugzilla at puremagic.com 2013-07-04 13:24:51 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/99265ca322625f9d76f2fcc530c83845d5485b37
Issue 10539 - Implicit pointer to array dereference for .ptr property fails
https://github.com/D-Programming-Language/dmd/commit/c7e0c6ef1085ce74e373b6096d2af40c958e32ec
Merge pull request #2296 from 9rnsr/fix10539
[REG2.063] Issue 10539 - Implicit pointer to array dereference for .ptr
property fails
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 13:24:59 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Thu, 4 Jul 2013 20:24:59 +0000 (UTC)
Subject: [Issue 10539] [REG][2.063] Implicit pointer to array dereference for
.ptr property fails
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10539
Walter Bright changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |bugzilla at digitalmars.com
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 17:25:55 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 00:25:55 +0000 (UTC)
Subject: [Issue 10545] New: Mostly portable way to set stdout/stdin mode
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10545
Summary: Mostly portable way to set stdout/stdin mode
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nobody at puremagic.com
ReportedBy: bearophile_hugs at eml.cc
--- Comment #0 from bearophile_hugs at eml.cc 2013-07-04 17:25:52 PDT ---
In Phobos I'd like a (portable across different operating systems) way to set
the mode of stdout/stdin (to binary or text mode).
A not portable way to do in C on Windows is:
setmode(fileno(stdout), O_BINARY);
In Python a not portable way to do it is (works on Windows):
import os, msvcrt
msvcrt.setmode(sys.stdout.fileno(), os.O_BINARY)
I think an almost portable way to do it is (this is a C99 version of freopen):
freopen(null, "wb", stdout);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 17:55:09 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 00:55:09 +0000 (UTC)
Subject: [Issue 10537] Forward reference error on 'yield' toy example.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10537
--- Comment #1 from Kenji Hara 2013-07-04 17:55:07 PDT ---
Reduced test case:
struct Iota10537
{
int s,e,i;
mixin Yield10537!q{ ; };
}
auto skipStrings10537(T)(T source)
{
return "";
}
mixin template Yield10537(dstring code)
{
alias X = typeof({ enum x = rewriteCode10537(code); }());
}
dstring rewriteCode10537(dstring code)
{
skipStrings10537(code); // IFTI causes forward reference
return "";
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 18:14:32 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 01:14:32 +0000 (UTC)
Subject: [Issue 10537] Forward reference error on 'yield' toy example.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10537
Kenji Hara changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |pull, rejects-valid
--- Comment #2 from Kenji Hara 2013-07-04 18:14:31 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2298
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 18:21:14 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 01:21:14 +0000 (UTC)
Subject: [Issue 10539] [REG][2.063] Implicit pointer to array dereference for
.ptr property fails
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10539
--- Comment #3 from github-bugzilla at puremagic.com 2013-07-04 18:21:13 PDT ---
Commit pushed to 2.063 at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/7e86fd874a6acc0a4dcc1250f37d15b9dbf40b97
Merge pull request #2296 from 9rnsr/fix10539
[REG2.063] Issue 10539 - Implicit pointer to array dereference for .ptr
property fails
Conflicts:
test/runnable/xtest46.d
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 21:29:01 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 04:29:01 +0000 (UTC)
Subject: [Issue 10537] Forward reference error on 'yield' toy example.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10537
--- Comment #3 from github-bugzilla at puremagic.com 2013-07-04 21:29:00 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/b275b48bad38267183e71050c5375066745e0e33
fix Issue 10537 - Forward reference error on 'yield' toy example.
https://github.com/D-Programming-Language/dmd/commit/fcf2ed507123c54f6c3e99ce281ae61fba55a340
Merge pull request #2298 from 9rnsr/fix10537
[REG2.063] Issue 10537 - Forward reference error on 'yield' toy example.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 21:31:20 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 04:31:20 +0000 (UTC)
Subject: [Issue 10537] Forward reference error on 'yield' toy example.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10537
yebblies changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
CC| |yebblies at gmail.com
Resolution| |FIXED
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Thu Jul 4 23:19:20 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 06:19:20 +0000 (UTC)
Subject: [Issue 10546] New: UFCS hides actual static assert failure in
opDispatch
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10546
Summary: UFCS hides actual static assert failure in opDispatch
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: minor
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: k.hara.pg at gmail.com
--- Comment #0 from Kenji Hara 2013-07-04 23:19:18 PDT ---
From: http://forum.dlang.org/post/zxhvyfitqkbvmfseyqxr at forum.dlang.org
struct Fail1
{
void opDispatch(string s)()
{
static assert(false, "Tried to call a method on Fail1");
}
}
struct Fail2
{
void opDispatch(string s, T)(T arg)
{
static assert(false, "Tried to call a method on Fail2");
}
}
void main()
{
auto fail1 = Fail1();
fail1.s(); // "no property" error instead of static asset failure
auto fail2 = Fail2();
fail2.s(1); // "no property" error instead of static asset failure
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 01:59:10 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 08:59:10 +0000 (UTC)
Subject: [Issue 10198] CTFE: Wrong code for multi-dimensional block assignment
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10198
Walter Bright changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |bugzilla at digitalmars.com
--- Comment #1 from Walter Bright 2013-07-05 01:59:05 PDT ---
https://github.com/D-Programming-Language/dmd/pull/2094
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 01:59:43 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 08:59:43 +0000 (UTC)
Subject: [Issue 10198] CTFE: Wrong code for multi-dimensional block assignment
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10198
--- Comment #2 from github-bugzilla at puremagic.com 2013-07-05 01:59:42 PDT ---
Commits pushed to master at https://github.com/D-Programming-Language/dmd
https://github.com/D-Programming-Language/dmd/commit/1962ce651883a323c73cfecbe01aa05c7bb16595
Fix issue 10198 CTFE struct Multidimensional block assignment
There are two bugs. (1) The code in todt.c ignored the possibility
that an initializer could be explicitly specified in the struct literal.
This is not the same as an initializer specified in the declaration of
the field.
This wrong behaviour was actually coded into a test in test42.d.
(2) The CTFE code didn't consider the multidimensional case.
https://github.com/D-Programming-Language/dmd/commit/b9b5c063d7f44b879d6fde74f400ff094ba85707
Merge pull request #2094 from donc/ctfe10198multiblock
Fix issue 10198 CTFE struct Multidimensional block assignment
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 02:00:04 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 09:00:04 +0000 (UTC)
Subject: [Issue 10198] CTFE: Wrong code for multi-dimensional block assignment
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10198
--- Comment #3 from Walter Bright 2013-07-05 02:00:03 PDT ---
Fixed for D2.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 03:05:44 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 10:05:44 +0000 (UTC)
Subject: [Issue 10547] New: DMD accepts function templates with no body.
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10547
Summary: DMD accepts function templates with no body.
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: brian-schott at cox.net
--- Comment #0 from brian-schott at cox.net 2013-07-05 03:05:42 PDT ---
DMD compiles the following code without complaining:
int templateFunction(A, B)(A a, B b);
>From the spec: "FunctionLiterals and function templates, since their function
bodies are always present, infer the pure, nothrow, and @safe attributes unless
specifically overridden."
Either the complier or the spec is wrong. The current iteration of my grammar
does not allow function bodies to be missing, since as far as I know, empty
function templates are useless aside from forcing DDoc generation.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 03:29:15 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 10:29:15 +0000 (UTC)
Subject: [Issue 10547] DMD accepts function templates with no body.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10547
Maxim Fomin changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |maxim at maxim-fomin.ru
--- Comment #1 from Maxim Fomin 2013-07-05 03:29:14 PDT ---
Current implementation allows to split template declaration and template
definition. You can place template declaration in .di file, full definition in
.d file and instantiate template with specific arguments. In module, which
imports .di file you can instantiate template if parameters match to those used
in .d file (this is limitation as due to separate compilation it is impossible
to know beforehand all potential parameters). Since instantiated function has
no body, dmd issues reference to external symbol and the trick works (in such
case compiler does not need template body but linker must find referenced
symbols). This allows to hide template definitions in D at the cost of reducing
potential possible parameters.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 03:38:39 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 10:38:39 +0000 (UTC)
Subject: [Issue 10547] DMD accepts function templates with no body.
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10547
brian-schott at cox.net changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords|accepts-invalid |
--- Comment #2 from brian-schott at cox.net 2013-07-05 03:38:39 PDT ---
Makes sense. I'm removing "accepts-invalid" but leaving "spec". I'll have to
update my parser and grammar.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 03:58:07 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 10:58:07 +0000 (UTC)
Subject: [Issue 10548] New: [REG 2.064a] argument has no identifier
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10548
Summary: [REG 2.064a] argument has no identifier
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nobody at puremagic.com
ReportedBy: yazan.dabain at gmail.com
--- Comment #0 from yazan.dabain at gmail.com 2013-07-05 03:58:06 PDT ---
import std.stdio, std.traits;
int foo(int num, string name);
void main() {
void bar(int num){}
static if (is(FunctionTypeOf!bar PT == __parameters)) {
pragma(msg, __traits(identifier, PT[0..1]));
}
}
Compiling this code using dmd 2.063, you get "num" printed out.
In dmd 2.064a, the compiler prints:
------
main.d(8): Error: argument int has no identifier
false
------
This regression is caused by commit: 877e7bf
pull request: https://github.com/D-Programming-Language/dmd/pull/1102
fixing: http://d.puremagic.com/issues/show_bug.cgi?id=3646
This is blocking: https://github.com/D-Programming-Language/phobos/pull/1378
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 04:46:51 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 11:46:51 +0000 (UTC)
Subject: [Issue 10549] New: Default object equality test not properly
implemented
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10549
Summary: Default object equality test not properly implemented
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nobody at puremagic.com
ReportedBy: anoneuron at gmail.com
--- Comment #0 from anoneuron at gmail.com 2013-07-05 04:46:49 PDT ---
In the base object class ("Object") the opEquals overload (which is inherited
as the default EqualExpression operation for objects) does not appear to be
implemented the way it is described.
The function is defined in object_.d
(http://github.com/D-Programming-Language/druntime/blob/master/src/object_.d)
as this:
/**
* Returns !=0 if this object does have the same contents as obj.
*/
bool opEquals(Object o)
{
return this is o;
}
(I'm not exactly sure what "!=0" is supposed to mean there, but I'll take it to
mean "true").
As I understand it, the "is" operator tests whether two object references refer
to the same instance, not whether "this object does have the same contents as
obj".
This also contradicts the official description of EqualExpression
(http://dlang.org/expression.html#EqualExpression):
"For class objects, the == and != operators compare the contents of the
objects."
Clearly, this functionality is not satisfied by an IdentityExpression.
Perhaps something like "this.tupleof == o.tupleof" would be more appropriate?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 05:49:15 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 12:49:15 +0000 (UTC)
Subject: [Issue 10543] std.algorithm.map incorrectly uses source range length
for narrow strings
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10543
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |accepts-invalid
Status|NEW |ASSIGNED
AssignedTo|nobody at puremagic.com |monarchdodra at gmail.com
--- Comment #8 from monarchdodra at gmail.com 2013-07-05 05:49:13 PDT ---
https://github.com/D-Programming-Language/phobos/pull/1389
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 05:57:32 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 12:57:32 +0000 (UTC)
Subject: [Issue 9975] pointsTo asserts because of false pointer in union
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=9975
--- Comment #14 from monarchdodra at gmail.com 2013-07-05 05:57:29 PDT ---
(In reply to comment #13)
> I'm really just wondering what business swap has asserting if there are
> pointers to either of the members... Having such a pointer is a *sign* of
> stink, but I don't think it is 100% certifiably wrong... in which case it
> should not assert.
Done: https://github.com/D-Programming-Language/phobos/pull/1390
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 06:54:09 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 13:54:09 +0000 (UTC)
Subject: [Issue 9543] Base64.decode shouldn't require source to have known
length
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=9543
monarchdodra at gmail.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |monarchdodra at gmail.com
--- Comment #1 from monarchdodra at gmail.com 2013-07-05 06:54:07 PDT ---
+1.
I had to deactivate a wrong-usage unittest in base64. It was trying to test
"input range", using map, which erroneously forwarded string length.
I fixed *that*, and the test blew up. So I deactivated it.
https://github.com/D-Programming-Language/phobos/pull/1389
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 06:58:36 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 13:58:36 +0000 (UTC)
Subject: [Issue 6594] Xorshift as default generator
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=6594
Joseph Rushton Wakeling changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |joseph.wakeling at webdrake.ne
| |t
--- Comment #1 from Joseph Rushton Wakeling 2013-07-05 06:58:35 PDT ---
Have to register a disagreement here. The default behaviour should be
statistically reliable -- choosing a faster but lower-quality RNG should be
done advisedly. We shouldn't reproduce the awful situation of C/C++ where the
default RNG is awful and users have to be educated to avoid it.
However, we could think about easy ways to specify the default RNG type Random
at compile-time.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 07:11:05 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 14:11:05 +0000 (UTC)
Subject: [Issue 10550] New: Xorshift32 and Xorshift160 do not generate
uniformly-distributed random numbers
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10550
Summary: Xorshift32 and Xorshift160 do not generate
uniformly-distributed random numbers
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nobody at puremagic.com
ReportedBy: joseph.wakeling at webdrake.net
--- Comment #0 from Joseph Rushton Wakeling 2013-07-05 07:11:03 PDT ---
The output of Xorshift32 and Xorshift160 departs strongly from uniformity.
The issue for Xorshift32 can be seen clearly even in this very simple piece of
code:
auto rng = Xorshift32(unpredictableSeed);
foreach(r; rng.take(20))
{
writeln(r, "\t", rng.min, "\t", rng.max);
}
... where we can see that the generated values are always much closer to
rng.min than rng.max.
A more sophisticated example (but still very simple) is provided in the test of
uniformity in https://github.com/WebDrake/std.random.test -- specifically, in:
https://github.com/WebDrake/std.random.test/blob/master/uniform.d
https://github.com/WebDrake/std.random.test/blob/master/test/stats.d
... which generates millions of random numbers using uniform(0.0, 0.1, rng),
divides them up into bins of width 0.05, and outputs the histogram and
cumulative distribution values.
For Xorshift32, this gives:
Generating 10000000 random numbers in [0, 1) with XorshiftEngine!(uint, 32, 13,
17, 5)
5 1 1
10 0 1
15 0 1
20 0 1
25 0 1
30 0 1
35 0 1
40 0 1
45 0 1
50 0 1
55 0 1
60 0 1
65 0 1
70 0 1
75 0 1
80 0 1
85 0 1
90 0 1
95 0 1
100 0 1
... while for Xorshift160 it gives:
Generating 10000000 random numbers in [0, 1) with XorshiftEngine!(uint, 160, 2,
1, 4)
5 0.0535713 0.0535713
10 0.0208334 0.0744047
15 0.0446429 0.119048
20 0.047619 0.166667
25 0.0714286 0.238095
30 0.0238096 0.261905
35 0.0208333 0.282738
40 0.0416667 0.324405
45 0.0595238 0.383929
50 0.0446429 0.428572
55 0.0476191 0.476191
60 0.0595239 0.535714
65 0.0714285 0.607143
70 0.0535714 0.660714
75 0.0535713 0.714286
80 0.0744045 0.78869
85 0.0744049 0.863095
90 0.0357143 0.898809
95 0.0238095 0.922619
100 0.0773811 1
Other RNGs, including other Xorshift types, appear to generate correct
proportions.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
From d-bugmail at puremagic.com Fri Jul 5 07:35:08 2013
From: d-bugmail at puremagic.com (d-bugmail at puremagic.com)
Date: Fri, 5 Jul 2013 14:35:08 +0000 (UTC)
Subject: [Issue 10550] Xorshift32 and Xorshift160 do not generate
uniformly-distributed random numbers
In-Reply-To:
References:
Message-ID:
http://d.puremagic.com/issues/show_bug.cgi?id=10550
--- Comment #1 from Joseph Rushton Wakeling