[Issue 10874] std.conv.to should support conversion from ulong to int-based enum
http://d.puremagic.com/issues/show_bug.cgi?id=10874 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #1 from hst...@quickfur.ath.cx 2013-08-22 21:07:02 PDT --- https://github.com/D-Programming-Language/phobos/pull/1505 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10610] interpret.c:4067 Assertion Failure
http://d.puremagic.com/issues/show_bug.cgi?id=10610 yebblies changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||FIXED --- Comment #3 from yebblies 2013-08-23 13:45:34 EST --- https://github.com/D-Programming-Language/dmd/commit/a3e447c6f91c48ff9362f6bb609252b0d4d758e8 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6384] std.traits.isComparable
http://d.puremagic.com/issues/show_bug.cgi?id=6384
--- Comment #2 from hst...@quickfur.ath.cx 2013-08-22 20:16:25 PDT ---
There are actually at least two possible isComparable's that would be helpful
in signature constraints. One checks if "a B.init is
valid. To that end, maybe we need isValidBinaryOp instead:
template isValidBinaryOp(T1, string op, T2) {
alias isValidBinaryOp = is(mixin("T1.init" ~ op ~ "T2.init") : bool);
}
then we could write signature constraints of the form:
auto myFunc(T,U)(T t, U u)
if (isValidBinaryOp!(T, "<", U))
{ ... }
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10874] New: std.conv.to should support conversion from ulong to int-based enum
http://d.puremagic.com/issues/show_bug.cgi?id=10874
Summary: std.conv.to should support conversion from ulong to
int-based enum
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: hst...@quickfur.ath.cx
--- Comment #0 from hst...@quickfur.ath.cx 2013-08-22 18:54:49 PDT ---
Code:
--
import std.conv;
enum Test { a = 0 }
void main() {
ulong l = 0;
auto t = l.to!Test;
}
--
DMD output:
/usr/src/d/phobos/std/conv.d(281): Error: template std.conv.toImpl does not
match any function template declaration. Candidates are:
/usr/src/d/phobos/std/conv.d(337):std.conv.toImpl(T, S)(S value) if
(isImplicitlyConvertible!(S, T) && !isEnumStrToStr!(S, T) && !isNullToStr!(S,
T))
/usr/src/d/phobos/std/conv.d(449):std.conv.toImpl(T, S)(ref S s) if
(isRawStaticArray!S)
/usr/src/d/phobos/std/conv.d(465):std.conv.toImpl(T, S)(S value) if
(is(typeof(S.init.opCast!T()) : T) && !isExactSomeString!T)
/usr/src/d/phobos/std/conv.d(496):std.conv.toImpl(T, S)(S value) if
(!isImplicitlyConvertible!(S, T) && is(T == struct) && is(typeof(T(value
/usr/src/d/phobos/std/conv.d(546):std.conv.toImpl(T, S)(S value) if
(!isImplicitlyConvertible!(S, T) && is(T == class) && is(typeof(new T(value
/usr/src/d/phobos/std/conv.d(281):... (16 more, -v to show) ...
/usr/src/d/phobos/std/conv.d(281): Error: template std.conv.toImpl(T, S)(S
value) if (isImplicitlyConvertible!(S, T) && !isEnumStrToStr!(S, T) &&
!isNullToStr!(S, T)) cannot deduce template function from argument types
!(Test)(ulong)
/usr/src/d/phobos/std/conv.d(281): Error: template instance toImpl!(Test)
errors instantiating template
test.d(5): Error: template instance std.conv.to!(Test).to!(ulong) error
instantiating
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 6893] Write of enum member represented with ubyte or ulong
http://d.puremagic.com/issues/show_bug.cgi?id=6893 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #7 from hst...@quickfur.ath.cx 2013-08-22 18:11:31 PDT --- https://github.com/D-Programming-Language/phobos/pull/1504 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6893] Write of enum member represented with ubyte or ulong
http://d.puremagic.com/issues/show_bug.cgi?id=6893 --- Comment #6 from hst...@quickfur.ath.cx 2013-08-22 18:08:22 PDT --- Argh. I wish bugzilla allowed editing of comments... What I meant was: getNthInt is called from inside a *runtime* if-condition that evaluates to false when the spec is "%s" and the argument is a ulong enum, but since this if-condition can only be checked at runtime, getNthInt must be able to compile in that case. Currently it doesn't compile because it assumes isIntegral!T means T can be implicitly converted to int, which is not true if the argument is a ulong (or a ulong enum). So the fix is to replace isIntegral with is(typeof(to!int(...))) so that at compile-time the compiler will hardcode the function to throw an exception when an invalid argument is given. (It won't actually throw at runtime if the if-condition in the caller evaluates to false at runtime.) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6893] Write of enum member represented with ubyte or ulong
http://d.puremagic.com/issues/show_bug.cgi?id=6893 --- Comment #5 from hst...@quickfur.ath.cx 2013-08-22 17:45:59 PDT --- Aha! I found the reason: getNthInt is called from a *compile-time* check, so even if the spec for enum is "%s", the compiler still has to compile this branch of the code. So the fix is for getNthInt to *statically* verify convertibility to int before attempting to call to!int. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6893] Write of enum member represented with ubyte or ulong
http://d.puremagic.com/issues/show_bug.cgi?id=6893 --- Comment #4 from Andrej Mitrovic 2013-08-22 17:33:31 PDT --- (In reply to comment #3) > Hmm actually, there appears to be a bug somewhere else. The spec shouldn't be > spec.DYNAMIC at all, since the default spec for enums is "%s". So something > went wrong before this point. Last time I tried to fix this I lost my head in the formatting jungle. Good luck! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6893] Write of enum member represented with ubyte or ulong
http://d.puremagic.com/issues/show_bug.cgi?id=6893 --- Comment #3 from hst...@quickfur.ath.cx 2013-08-22 17:31:41 PDT --- Hmm actually, there appears to be a bug somewhere else. The spec shouldn't be spec.DYNAMIC at all, since the default spec for enums is "%s". So something went wrong before this point. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6893] Write of enum member represented with ubyte or ulong
http://d.puremagic.com/issues/show_bug.cgi?id=6893 --- Comment #2 from hst...@quickfur.ath.cx 2013-08-22 17:21:19 PDT --- The problem appears to be std.format.getNthInt, under "static if (isIntegral!...)": the code assumes that if a type is integral, it can be converted to int, but this is not true when the base type of the enum is ulong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10873] Refused extern(C) function type definition with new alias syntax
http://d.puremagic.com/issues/show_bug.cgi?id=10873 Andrej Mitrovic changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #1 from Andrej Mitrovic 2013-08-22 17:09:56 PDT --- *** This issue has been marked as a duplicate of issue 10471 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10873] New: Refused extern(C) function type definition with new alias syntax
http://d.puremagic.com/issues/show_bug.cgi?id=10873
Summary: Refused extern(C) function type definition with new
alias syntax
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-08-22 17:06:59 PDT ---
alias extern(C) void* function(in size_t size) nothrow T1; // OK
alias T2 = extern(C) void* function(in size_t size) nothrow; // Error
void main() {}
dmd 2.064alpha:
test.d(2): Error: basic type expected, not extern
test.d(2): Error: semicolon expected to close alias declaration
test.d(2): Error: no identifier for declarator extern (C) void* function(in
size_t size) nothrow
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10471] New alias syntax can't handle extern qualifiers
http://d.puremagic.com/issues/show_bug.cgi?id=10471 Andrej Mitrovic changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #2 from Andrej Mitrovic 2013-08-22 17:09:56 PDT --- *** Issue 10873 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4085] Steps toward a static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=4085
--- Comment #11 from bearophile_h...@eml.cc 2013-08-22 16:53:06 PDT ---
Another comment by Timon Gehr:
> We really need to define a consistent semantics for compile
> time symbol manipulation though.
>
> Eg:
>
> class C{
> int a;
> static foreach(x;__traits(allMembers,C)){
> mixin("int "~__traits(identifier,x)~"b;");
> }
> }
>
> What is this supposed to do? "class C{ int a,ab; }"?
> Non-terminating compilation? Error?
>
> My best guess is that the above code should be illegal,
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4085] Steps toward a static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=4085
--- Comment #10 from bearophile_h...@eml.cc 2013-08-22 16:50:01 PDT ---
Adapted from two comments by Timon Gehr:
> It's important to keep them separate regardless. static foreach is close
> to useless if it introduces a new scope for its body.
>
> I.e.:
>
> int main() {
> foreach (_; Seq!int) {
> int x;
> }
> return x; // error
> }
>
> int main() {
> static foreach (_; Seq!int) {
> int x;
> }
> return x; // ok
> }
>
> I think the relationship between foreach and static foreach
> should essentially mirror that of if and static if.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10872] New: Typedef and const
http://d.puremagic.com/issues/show_bug.cgi?id=10872 Summary: Typedef and const Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: john.loughran.col...@gmail.com --- Comment #0 from John Colvin 2013-08-22 23:55:25 BST --- alias Typedef!(const(void*)) CVP; CVP cvp; //Error: cannot modify const expression Typedef_payload -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10871] Typedef doesn't work with is null
http://d.puremagic.com/issues/show_bug.cgi?id=10871 --- Comment #2 from John Colvin 2013-08-22 23:17:08 BST --- (In reply to comment #1) > I'm not sure how we could implement this, we don't have an "opIs" operator. yeah I have no idea either. Is there any other way of getting something like a type-safe alias? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10871] New: Typedef doesn't work with is null
http://d.puremagic.com/issues/show_bug.cgi?id=10871
Summary: Typedef doesn't work with is null
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: john.loughran.col...@gmail.com
--- Comment #0 from John Colvin 2013-08-22
23:05:22 BST ---
import std.typecons;
alias Typedef!(void*) VP;
void main()
{
VP vp;
assert(vp is null); //won't compile
}
Error: incompatible types for ((vp) is (null)): 'Typedef!(void*, null)' and
'typeof(null)'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10871] Typedef doesn't work with is null
http://d.puremagic.com/issues/show_bug.cgi?id=10871 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2013-08-22 15:09:02 PDT --- I'm not sure how we could implement this, we don't have an "opIs" operator. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8848] Array literals and AA literals are rejected as template value parameters
http://d.puremagic.com/issues/show_bug.cgi?id=8848
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #3 from Andrej Mitrovic 2013-08-22
14:41:26 PDT ---
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > The template spec says that they are valid (both D1 and D2),
> >
> > So are associative arrays accepted, but simple arrays aren't?
> >
> > template Foo(int[] X) {}
> > template Bar(int[5] X) {}
> > void main() {}
>
> No, the current DMD accepts neither arrays or AAs in declarations. But both
> can
> be passed in template tuple parameters.
W.r.t. arrays, is this just a parser issue? It's odd that we have this
situation:
-
// template Foo(ubyte[]) { } // nogo
template Bar(T...) { } // ok
void main()
{
enum ubyte[] x = [1, 2];
// alias y = Foo!(x);
alias z = Bar!(x); // ok
}
-
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10610] interpret.c:4067 Assertion Failure
http://d.puremagic.com/issues/show_bug.cgi?id=10610 --- Comment #2 from Don 2013-08-22 12:45:24 PDT --- https://github.com/D-Programming-Language/dmd/pull/2495 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9954] Runtime wrong code with global interface var created in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=9954 Don 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: ---
[Issue 10869] Ddoc mark methods with "const" twice
http://d.puremagic.com/issues/show_bug.cgi?id=10869 Andrej Mitrovic changed: What|Removed |Added Keywords||ddoc, pull Version|unspecified |D2 AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic 2013-08-22 10:05:17 PDT --- https://github.com/D-Programming-Language/dmd/pull/2494 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10869] Ddoc mark methods with "const" twice
http://d.puremagic.com/issues/show_bug.cgi?id=10869 --- Comment #3 from Andrej Mitrovic 2013-08-22 10:06:29 PDT --- There's another problem, synchronized methods were usually handled in the prefix function, which output "synchronized", but then MODtoBuffer in toCBufferWithAttributes outputs "shared". So I'll file this as another bug once this pull is merged first. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10870] Ddoc adds "abstract" to interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=10870 Andrej Mitrovic changed: What|Removed |Added Keywords||pull --- Comment #1 from Andrej Mitrovic 2013-08-22 09:48:58 PDT --- https://github.com/D-Programming-Language/dmd/pull/2493 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10869] Ddoc mark methods with "const" twice
http://d.puremagic.com/issues/show_bug.cgi?id=10869 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2013-08-22 09:39:11 PDT --- Introduced by f5f71ce1f50f2c33240475c44376cf176b75217e by fixing Issue 3445. prefix is first called in declarationToDocBuffer, which adds one or more of these: deprecated static final abstract const immutable synchronized But then toCBufferWithAttributes for functions is called which adds one or more of these when it calls MODtoBuffer: immutable shared const inout So there's a bit of an overlap. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10870] New: Ddoc adds "abstract" to interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=10870 Summary: Ddoc adds "abstract" to interfaces Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d...@me.com --- Comment #0 from Jacob Carlborg 2013-08-22 09:30:14 PDT --- Example: std.stream.InputStream http://dlang.org/phobos/std_stream.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10869] New: Methods are marked with "const" twice
http://d.puremagic.com/issues/show_bug.cgi?id=10869 Summary: Methods are marked with "const" twice Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d...@me.com --- Comment #0 from Jacob Carlborg 2013-08-22 09:26:14 PDT --- In std.xml all methods that are const are marked with "const" twice. http://dlang.org/phobos/std_xml.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10868] std.string.translate should take an optional buffer
http://d.puremagic.com/issues/show_bug.cgi?id=10868 Brad Anderson changed: What|Removed |Added CC||e...@gnuk.net --- Comment #5 from Brad Anderson 2013-08-22 09:06:38 PDT --- (In reply to comment #1) > I think that we should move towards having pretty much any Phobos function > which allocates an array (including strings) have an overload which takes an > output range to write to instead. However, we should probably make sure that > output ranges are appropriately ironed out before we do that heavily (e.g. we > really need to have a clear way of asking whether an output range is full). > Input ranges are used heavily, but output ranges have had much less attention > and may need additional work before they're used that heavily. Monarch's https://github.com/D-Programming-Language/phobos/pull/1439 improves the Output Range situation quite a bit. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10868] std.string.translate should take an optional buffer
http://d.puremagic.com/issues/show_bug.cgi?id=10868 Andrej Mitrovic changed: What|Removed |Added Keywords||pull --- Comment #4 from Andrej Mitrovic 2013-08-22 07:38:06 PDT --- https://github.com/D-Programming-Language/phobos/pull/1501 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9645] std.algorithm.splitter on string with char as separator performs badly in certain situations
http://d.puremagic.com/issues/show_bug.cgi?id=9645 monarchdo...@gmail.com changed: What|Removed |Added CC||monarchdo...@gmail.com --- Comment #2 from monarchdo...@gmail.com 2013-08-22 07:36:21 PDT --- (In reply to comment #0) > char splitter took 2 secs, 702 ms, and 188 μs > > substring splitter took 1 sec, 71 ms, and 736 μs Changes where made to improve the situation, However, due to performance bug 10848, it is still slower. That said, I have a standing performance improvement pull for find: https://github.com/D-Programming-Language/phobos/pull/1492 fix Issue 10403 - memchr optimization for std.algorithm.find http://d.puremagic.com/issues/show_bug.cgi?id=10403 With it, I'm getting: char splitter took 429 ms, 298 μs, and 8 hnsecs substring splitter took 2 secs, 323 ms, 301 μs, and 7 hnsecs Gone from twice as slow to five times as fast. Not bad :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5842] hash table corruption
http://d.puremagic.com/issues/show_bug.cgi?id=5842 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from hst...@quickfur.ath.cx 2013-08-22 07:39:51 PDT --- Verified fixed in git HEAD. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10383] redundant splitter implementations conflict with each other
http://d.puremagic.com/issues/show_bug.cgi?id=10383 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||monarchdo...@gmail.com Resolution||DUPLICATE --- Comment #1 from monarchdo...@gmail.com 2013-08-22 06:37:20 PDT --- I'll fix this shortly. *** This issue has been marked as a duplicate of issue 6730 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6730] std.algorithm.splitter conflicts with std.array.splitter
http://d.puremagic.com/issues/show_bug.cgi?id=6730 monarchdo...@gmail.com changed: What|Removed |Added CC||dmitry.o...@gmail.com --- Comment #4 from monarchdo...@gmail.com 2013-08-22 06:37:21 PDT --- *** Issue 10383 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10806] Interface covariance for more than one interface at once also broken
http://d.puremagic.com/issues/show_bug.cgi?id=10806 --- Comment #3 from FeepingCreature 2013-08-22 01:54:04 PDT --- > Additional example: > > http://dpaste.dzfl.pl/a390f1f4 That's not the same bug. The only issue with that code is that the compiler fails to warn you that the call to foo() is ambiguous. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10862] Assignment inside if condition still sometimes accepted
http://d.puremagic.com/issues/show_bug.cgi?id=10862 monarchdo...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #20 from monarchdo...@gmail.com 2013-08-22 01:38:02 PDT --- Confirmed fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5842] hash table corruption
http://d.puremagic.com/issues/show_bug.cgi?id=5842 --- Comment #2 from github-bugzi...@puremagic.com 2013-08-22 01:36:53 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/8df0da02f3e290e54b131452663dbf24d1ca88d1 Fix bug 5842. The bug is caused by rehash producing an AA with a zero-size hashtable when called on an empty but non-null AA. https://github.com/D-Programming-Language/druntime/commit/8e5a7bd8d7dd99420d50d92bc7a85ef61b140275 Merge pull request #576 from quickfur/issue5842 Fix bug 5842. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9937] CTFE floats don't overflow correctly
http://d.puremagic.com/issues/show_bug.cgi?id=9937 --- Comment #19 from Don 2013-08-22 00:57:25 PDT --- (In reply to comment #18) > (In reply to comment #15) > > Don, I think we've reached an impasse here. How about we duke it out at > > Dcon? I > > think some beers will get us to a solution! > > And the result is? Well, we didn't spend much time on it. I've realized a few things since then: (1) My statement about x87 being the only case where you can get extra precision, is wrong. Machines with FMA can effectively have twice double precision on some operations. The 80-precision that DMD currently uses, is actually not enough, even for x86-64. (2) We have a few things conflated here. The most severe bug in the current situation is the example in comment 4: the compiler acts as though extra bits of precision can be transferred from compile time to run time. This has a simple solution, see below. (3) The solution to my initial test case is less clear. There needs to be a way to reliably dump extra precision from a calculation. Walter's example in comment 10 is one possibility. Now, to fix comment 4: All that needs to happen to fix this, is that floating point values should be rounded to fit the target type *at the end of CTFE*, as part of the existing scrubbing process. They should not be carrying extra precision that could not possibly exist at runtime. This rounding does not apply to const-folding (where things such as inlining could happen which might preserve more precision). The philosophy then would be, const-folding never reduces precision below what the machine can support. But in cases where a CTFE value must be created, such as in a template value parameter, the result has a single value throughout the program. Any extra precision it used in generating that value is entirely CTFE's business and should not leak into the rest of the compiler. Now that I've split CTFE off completely from const-folding, it's possible to make this distinction. This would fix the issue in comment 4, but doesn't affect anything else. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10862] Assignment inside if condition still sometimes accepted
http://d.puremagic.com/issues/show_bug.cgi?id=10862 --- Comment #19 from github-bugzi...@puremagic.com 2013-08-22 00:07:17 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/34e4acf514eff195b76c614102f8050255f79b36 fix issue 10862 - Assignment inside if condition still sometimes accepted https://github.com/D-Programming-Language/dmd/commit/297a3e0980a6938be52d2f1209fd29aecf96df95 Merge pull request #2491 from hpohl/10862 fix issue 10862 - Assignment inside if condition still sometimes accepted -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
