[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: ---
