[Issue 9615] New: std.conv.parse!(T[]) fails on trailing comma
http://d.puremagic.com/issues/show_bug.cgi?id=9615 Summary: std.conv.parse!(T[]) fails on trailing comma Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2013-02-28 01:01:53 PST --- The D syntax (AFAIK) allows a trailing comma at the end of a list, for the sake of convenience, eg: int a = [ 1, 2, 3, ]; (This *is* legal, right, it's not an accepts invalid?) In any case, this code is currently legal, but std.conv.pase rejects it: // int[] arr = [1, 2,]; //LEGAL string s = [1, 2,]; //*SHOULD* work parse!(int[])(s); //Unexpected ']' when converting from type string to type int // -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9615] std.conv.parse!(T[]) fails on trailing comma
http://d.puremagic.com/issues/show_bug.cgi?id=9615 --- Comment #1 from monarchdo...@gmail.com 2013-02-28 01:12:58 PST --- (In reply to comment #0) parse!(int[])(s); //Unexpected ']' when converting from type string to type int And if you are trying to parse a string[], you'll get a Can't parse string: is missing -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3502] Fix for dropped Mac OS X 10.5
http://d.puremagic.com/issues/show_bug.cgi?id=3502 Martin Nowak c...@dawg.eu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Martin Nowak c...@dawg.eu 2013-02-28 04:10:25 PST --- On OSX 10.5.2 the XCode3.0 linker (ld64-77) still crashes when handling debug_line sections with an empty line table because it calculates the wrong minimal section length. This bug is still present on ld64-134.9 but they fixed the symptom by adding a NULL check in ld64-87. http://www.opensource.apple.com/source/ld64/ld64-97.2/ChangeLog 2008-07-18 Nick Kledzikkled...@apple.com * src/MachOReaderRelocatable.hpp: don't crash if debug_line section has no line table -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3502] Fix for dropped Mac OS X 10.5
http://d.puremagic.com/issues/show_bug.cgi?id=3502 --- Comment #9 from Martin Nowak c...@dawg.eu 2013-02-28 04:14:37 PST --- Created an attachment (id=1196) ld64-77 patch -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3502] Fix for dropped Mac OS X 10.5
http://d.puremagic.com/issues/show_bug.cgi?id=3502 Martin Nowak c...@dawg.eu changed: What|Removed |Added Attachment #1196|0 |1 is obsolete|| --- Comment #10 from Martin Nowak c...@dawg.eu 2013-02-28 04:28:15 PST --- Created an attachment (id=1197) ld64-77 patch -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9347] new std.signals2 implementation
http://d.puremagic.com/issues/show_bug.cgi?id=9347 --- Comment #2 from jfanati...@gmx.at 2013-02-28 05:43:16 PST --- (In reply to comment #1) (In reply to comment #0) The current std.signals implementation has various short comings. For closure related shortcomings see Issue 9603. I also would like to have a compiler solution of it instead of a library one (see Issue 9603 Comment 1). The new implementation supports wrapping delegates, this is fact was a very important feature for me. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9347] new std.signals2 implementation
http://d.puremagic.com/issues/show_bug.cgi?id=9347 --- Comment #3 from Denis Shelomovskij verylonglogin@gmail.com 2013-02-28 18:11:02 MSK --- (In reply to comment #2) The new implementation supports wrapping delegates, this is fact was a very important feature for me. But it doesn't do it correctly as it can't because of absence of stuff for controlling/watching delegate lifetime in D. See bug 9603 comment 2 for a test case. Also new implementation doesn't handle threading issue 9606. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8441] mixin containing template functions causes compiler errors
http://d.puremagic.com/issues/show_bug.cgi?id=8441 --- Comment #10 from jfanati...@gmx.at 2013-02-28 08:26:34 PST --- (In reply to comment #8) I don't test std.signal2 module, but the two test cases work with my patch. https://github.com/D-Programming-Language/dmd/pull/1660 std.signal2 works too! Thank you! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9613] Parser bug when using .init with type constructor
http://d.puremagic.com/issues/show_bug.cgi?id=9613 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Keywords||pull AssignedTo|nob...@puremagic.com|andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-02-28 13:36:49 PST --- https://github.com/D-Programming-Language/dmd/pull/1703 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9616] New: SortedRange should support all range kinds
http://d.puremagic.com/issues/show_bug.cgi?id=9616 Summary: SortedRange should support all range kinds Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: and...@erdani.com --- Comment #0 from Andrei Alexandrescu and...@erdani.com 2013-02-28 15:26:41 PST --- There's no inherent reason for which SortedRange shouldn't support all kinds of ranges. There are e.g. files that are known to be sorted, and there are algorithms on sorted ranges that don't need random access, such as merge, diff etc. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9616] SortedRange should support all range kinds
http://d.puremagic.com/issues/show_bug.cgi?id=9616 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc Severity|normal |enhancement --- Comment #1 from bearophile_h...@eml.cc 2013-02-28 15:50:26 PST --- I have converted this to an enhancement request, if that's OK. Is this ER vaguely related to this question I have asked? http://forum.dlang.org/thread/zmiqbifxevljazceo...@forum.dlang.org If SortedRange supports Input Ranges too, then group(SortedRange) is able to be a SortedRange. But unfortunately if you apply an array on that lazy SortedRange, you get an array and you lose the SortedRange quality. In my code I'd like to perform a binary search on the result of a sort.group.array. Currently I have to use sort.group.array.assumeSorted. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9617] New: ulong.max is wrongly accepted by smaller signed parameter
http://d.puremagic.com/issues/show_bug.cgi?id=9617 Summary: ulong.max is wrongly accepted by smaller signed parameter Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: accepts-invalid Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: k.hara...@gmail.com --- Comment #0 from Kenji Hara k.hara...@gmail.com 2013-02-28 17:45:44 PST --- This is wrong implicit conversion bug. void main() { void f1(int) {} void f2(short) {} void f3(byte) {} // Why these calls are accepted? f1(ulong.max); f2(ulong.max); f3(ulong.max); // But, if argument is not constant value, compilation fails. ulong x; //f1(x); // is not callable using argument types (ulong) //f2(x); // is not callable using argument types (ulong) //f3(x); // is not callable using argument types (ulong) void f4(uint) {} void f5(ushort) {} void f6(ubyte) {} // If parameter type is unsigned, it is collectly rejected //f4(ulong.max); // is not callable using argument types (ulong) //f5(ulong.max); // is not callable using argument types (ulong) //f6(ulong.max); // is not callable using argument types (ulong) } -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9617] ulong.max is wrongly accepted by smaller signed parameter
http://d.puremagic.com/issues/show_bug.cgi?id=9617 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-02-28 18:16:25 PST --- https://github.com/D-Programming-Language/dmd/pull/1704 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8993] Implement unique references/isolated memory
http://d.puremagic.com/issues/show_bug.cgi?id=8993 --- Comment #14 from bearophile_h...@eml.cc 2013-02-28 18:37:48 PST --- See also: https://github.com/D-Programming-Language/dmd/pull/1700 http://wiki.dlang.org/DIP29 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9618] New: DMD takes unnecessary route to alias this in certain situations
http://d.puremagic.com/issues/show_bug.cgi?id=9618 Summary: DMD takes unnecessary route to alias this in certain situations Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: pun...@coverify.org --- Comment #0 from Puneet Goel pun...@coverify.org 2013-02-28 19:21:28 PST --- I am using the latest DMD github snapshot. The following reduced code gives me an error on line 4: test.d(4): Error: e2ir: cannot cast b.barObj.val of type int to type test.BarBase The error disappears if I comment out the alias this on line 10. As per my analysis, the following conditions must be met for the error to appear. 1. At least one (correct) alias this mapping should have already happened. In this example, that mapping is from Bar - BarObj 2. An implicit upcast is required after the first alias mapping has occurred. In the example that upcast is from BarObj - BarBase In such situations, DMD is not looking at the possible upcast if further alias this is possible. It does (incorrect) mapping to alias this and ends up in a compile failure. class Foo(T) { // 1 T a ; // 2 void bind(Bar b) {// 3 this.a = b; // 4 } // 5 } // 6 class BarBase{} // 7 class BarObj: BarBase { // 8 int val; // 9 alias val this; // 10 } // 11 class Bar { // 12 BarObj barObj;// 13 alias barObj this;// 14 } // 15 class Top { // 16 Bar bar; // 17 Foo!(BarBase) foo;// 18 this() { // 19 foo.bind(bar); // 20 } // 21 } // 22 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9619] New: Failed struct field typeof in inner function
http://d.puremagic.com/issues/show_bug.cgi?id=9619 Summary: Failed struct field typeof in inner function 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-02-28 19:48:50 PST --- struct Foo { int x; } void main() { void bar() { typeof(Foo.x) y; } } DMD 2.063alpha gives: test.d(4): Error: this is not in a class or struct scope test.d(4): Error: 'this' is only defined in non-static member functions, not bar -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9619] Failed struct field typeof in inner function
http://d.puremagic.com/issues/show_bug.cgi?id=9619 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Platform|x86 |All OS/Version|Windows |All --- Comment #1 from Kenji Hara k.hara...@gmail.com 2013-02-28 19:59:19 PST --- https://github.com/D-Programming-Language/dmd/pull/1687 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9620] New: Error messages of failed pure enforcement
http://d.puremagic.com/issues/show_bug.cgi?id=9620 Summary: Error messages of failed pure enforcement Product: D Version: D2 Platform: x86 OS/Version: Windows Status: NEW Keywords: diagnostic Severity: minor Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2013-02-28 19:59:45 PST --- I don't know if this is a bug, or if it's OK. This is wrong code: import std.range: chain; void main() pure { static void foo() { int[] a; chain(a, a); } foo(); } DMD 2.063alpha gives: test1.d(5): Error: pure function 'main' cannot call impure function 'chain' Is it right for the error message to say that main calls chain (while it's called by foo)? This similar code is a simpler example: void foo(int[]) {} void main() pure { static void bar() { int[] a; foo(a); } bar(); } It gives: test2.d(5): Error: pure function 'D main' cannot call impure function 'test2.foo' Note how in the first error message dmd uses 'main' and in the second 'D main'. I don't know why there is such difference. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9260] getopt should allow setting booleans to false
http://d.puremagic.com/issues/show_bug.cgi?id=9260 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #2 from hst...@quickfur.ath.cx 2013-02-28 20:00:41 PST --- Would it be too much to support --no-flagname as a synonym for --flag=false? For example, --verbose means --verbose=true, --no-verbose means --verbose=false. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7520] opDollar undocumented
http://d.puremagic.com/issues/show_bug.cgi?id=7520 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #2 from hst...@quickfur.ath.cx 2013-02-28 20:12:58 PST --- I've used opDollar in some of my code; it appears to work like this: obj[$] gets lowered to obj.opIndex(obj.opDollar!0); obj[1,$] gets lowered to obj.opIndex(1, obj.opDollar!1); obj[1,2,$] gets lowered to obj.opIndex(1, 2, obj.opDollar!2); and so on. The $ is recognized in subexpressions as well, so: obj[1, func(2,$), 3] gets lowered to obj.opIndex(1, func(2, obj.opDollar!1), 3). In other words, the compile-time argument of opDollar is the index of position it appears in, in the arguments of the indexing operator. Unfortunately, it appears that only opDollar!0 is implemented for opSlice (besides, slicing syntax currently does not support multiple ranges). aside But even with the current opIndex and opDollar, one can hack around the lack of multidimensional opSlice by defining a custom range type, say: struct Range { int start,end; }, then you can overload opIndex to recognize pseudo-slicing syntax: obj[Range(1,2), Range(2,$)] gets translated to obj.opIndex(Range(1,2), Range(2,obj.opDollar!1)), so you just have to define: auto opIndex(Range r1, Range r2), and you can have pseudo-multidimensional slicing. One can even use variadic parameters to handle a mix of slicing and indexing: auto opIndex(R...)(R args) { foreach (arg; args) { static if (typeof(arg) : Range) { // slice this dimension } else if (typeof(arg) : indexType) { // index this dimension } } } The $'s are correctly translated to opDollar!i based on their position i in the [] operator, so this will correctly handle things like obj[$-1, Range(0,$-1)], obj[Range(0,$), 10], etc.. /aside -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1528] [tdpl] overloading template and non-template functions
http://d.puremagic.com/issues/show_bug.cgi?id=1528 --- Comment #16 from Kenji Hara k.hara...@gmail.com 2013-02-28 20:46:30 PST --- (In reply to comment #13) // vs specialized parameter int f4(int a) { return 1; } int f4(T:int)(T b) { return 2; } static assert(f4(1)==1); Just only this is wrong. f4(T:int) is specialized to int argument, so f4(1) could match both normal function version and template version *with the same extent*. Then it will be ambiguous. static assert(f4(1L)==1); Ok. f4(T:int) cannot instantiate with T==long, so first version will be called. (In reply to comment #15) (In reply to comment #14) ... static assert(f6(1L) == 1); static assert(f6(ulong.max) == 2); // (a) ??? No match. ulong ul = runtime(); static assert(f6(ul) == 2);// (b) ??? No match. Both (a) and (b) should be no match, but with my experimental change, (a) wrongly matches to int. I found an another bug in there, and filed it as bug 9617. Current test case results with my pull request: https://github.com/D-Programming-Language/dmd/pull/1409 is: int f1(int a, double=10) { return 1; } int f1(int a, string=) { return 2; } int f2(T:int)(T b, double=10) { return 1; } int f2(T:int)(T b, string=) { return 2; } // vs deduced parameter int f3(int a) { return 1; } int f3(T)(T b) { return 2; } // vs specialized parameter int f4(int a) { return 1; } int f4(T:int)(T b) { return 2; } // vs deduced parameter + template constraint (1) int f5(int a) { return 1; } int f5(T)(T b) if (is(T == int)) { return 2; } // vs deduced parameter + template constraint (2) int f6(int a) { return 1; } int f6(T)(T b) if (is(T : int)) { return 2; } // vs nallowing conversion int f7(ubyte a) { return 1; } int f7(T)(T b) if (is(T : int)) { return 2; } void main() { static assert(!__traits(compiles, f1(1))); // ambiguous static assert(!__traits(compiles, f1(1L))); // ambiguous static assert(!__traits(compiles, f2(1))); // ambiguous static assert(!__traits(compiles, f2(1L))); // no match assert(f3(1) == 1); assert(f3(1L) == 2); static assert(!__traits(compiles, f4(1))); assert(f4(1L) == 1); assert(f5(1) == 1); assert(f5(1L) == 1); assert(f6(1) == 1); assert(f6(1L) == 1); static assert(!__traits(compiles, f6(ulong.max))); // no match // needs to fix bug 9617 ulong ulval = 1; static assert(!__traits(compiles, f6(ulval))); // no match assert(f7(200u) == 2); assert(f7(400u) == 2); uint uival = 400; // TDPL-like range knowledge lost here. assert(f7(uival) == 2); a = 200;// Ditto. assert(f7(uival) == 2); } I welcome more complicated test case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---