[Issue 12160] UDA related regressions
https://d.puremagic.com/issues/show_bug.cgi?id=12160 --- Comment #8 from github-bugzi...@puremagic.com 2014-02-15 00:05:17 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/23d14e7cfe69c677be1e7d06378741db50fe0eb4 fix Issue 12160 - UDA related regressions https://github.com/D-Programming-Language/dmd/commit/759e4a1dd9c09bb1a307f75fb3962706e87a38cc Merge pull request #3266 from 9rnsr/fix12160 [REG2.065a] Issue 12160 - UDA related regressions -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12160] UDA related regressions
https://d.puremagic.com/issues/show_bug.cgi?id=12160 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12163] pdb debugging (win64): stepping loops points to incorrect lines
https://d.puremagic.com/issues/show_bug.cgi?id=12163 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de Platform|x86_64 |All --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2014-02-15 00:26:47 PST --- It's the same for win32, I suspect it is similar with DWARF output. The reason probably is that there is no line number info for the closing braces. The patch to create lexical scope might help here: https://github.com/D-Programming-Language/dmd/pull/2867 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12163] pdb debugging (win64): stepping loops points to incorrect lines
https://d.puremagic.com/issues/show_bug.cgi?id=12163 yazan.dab...@gmail.com changed: What|Removed |Added CC||yazan.dab...@gmail.com OS/Version|Windows |All --- Comment #2 from yazan.dab...@gmail.com 2014-02-15 01:39:57 PST --- The same behavior can be observed on Linux with DWARF symbols. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12169] New: sum(int[]) should return a int
https://d.puremagic.com/issues/show_bug.cgi?id=12169
Summary: sum(int[]) should return a int
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-02-15 01:44:01 PST ---
import std.algorithm: sum;
void main() {
int[] arr1;
auto arr2 = new int[arr1.sum];
}
With dmd 2.065beta3 gives:
test3.d(4,25): Error: cannot implicitly convert expression (sum(arr1)) of type
long to uint
It seems a sum(int[]) gives a long. 99% of the cases this is not what I need.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
https://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #24 from bearophile_h...@eml.cc 2014-02-15 01:44:42 PST --- See Issue 12169 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12170] New: sum(double[]) is not pure
https://d.puremagic.com/issues/show_bug.cgi?id=12170
Summary: sum(double[]) is not pure
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-02-15 01:48:01 PST ---
import std.algorithm;
void main() pure {
[1.0].sum;
}
dmd 2.065beta3 gives:
test.d(3,10): Error: pure function 'D main' cannot call impure function
'std.algorithm.sum!(double[]).sum'
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
https://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #25 from bearophile_h...@eml.cc 2014-02-15 01:48:32 PST --- See Issue 12170 for another problem -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12171] New: Refused UFCS call for a sum()
https://d.puremagic.com/issues/show_bug.cgi?id=12171
Summary: Refused UFCS call for a sum()
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 2014-02-15 01:52:12 PST ---
import std.algorithm: sum;
void main() {
enum int[] arr1 = [10, 20];
int[arr1.sum] arr2;
}
dmd 2.065beta3 gives:
test.d(4,19): Error: no property 'sum' for type 'int[]'
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
https://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #26 from bearophile_h...@eml.cc 2014-02-15 01:53:08 PST --- See also Issue 12171 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12163] pdb debugging (win64): stepping loops points to incorrect lines
https://d.puremagic.com/issues/show_bug.cgi?id=12163 Manu turkey...@gmail.com changed: What|Removed |Added Severity|major |critical --- Comment #3 from Manu turkey...@gmail.com 2014-02-15 01:57:08 PST --- Right, so it seems it's a line numbering thing rather than a win64/pdb thing. I think that calls for a bump in priority if debugging experience on all platforms is crooked. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
https://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #27 from bearophile_h...@eml.cc 2014-02-15 02:01:58 PST --- Another problem is in Issue 12172 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12172] New: Refused sum(transversal)
https://d.puremagic.com/issues/show_bug.cgi?id=12172
Summary: Refused sum(transversal)
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-02-15 02:01:19 PST ---
import std.algorithm: reduce, sum;
import std.range: transversal;
alias mySum = reduce!q{a + b};
void main() {
const data = [[1, 2], [10, 20]];
mySum(0, data.transversal(0)); // OK
sum(0, data.transversal(0)); // Error
}
dmd 2.065beta3 gives:
test.d(7,8): Error: template std.algorithm.sum cannot deduce function from
argument types !()(int, Transversal!(const(int[])[],
cast(TransverseOptions)0)), candidates are:
...\dmd2\src\phobos\std\algorithm.d(1070,6):std.algorithm.sum(R)(R r)
if (isInputRange!R !isFloatingPoint!(ElementType!R) !isInfinite!R)
...\dmd2\src\phobos\std\algorithm.d(1115,6):std.algorithm.sum(R)(R r)
if (hasSlicing!R hasLength!R isFloatingPoint!(ElementType!R))
...\dmd2\src\phobos\std\algorithm.d(1145,6):std.algorithm.sum(R)(R r)
if (isInputRange!R !(hasSlicing!R hasLength!R)
isFloatingPoint!(ElementType!R) !isInfinite!R)
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12135] [AA] Format tail after associative array value is treated as separator if explicit separator is empty
https://d.puremagic.com/issues/show_bug.cgi?id=12135 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7666] A function to reverse the items of a tuple
https://d.puremagic.com/issues/show_bug.cgi?id=7666 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2776] pragma(lib, does not work when used in headers
https://d.puremagic.com/issues/show_bug.cgi?id=2776 --- Comment #7 from Jacob Carlborg d...@me.com 2014-02-15 02:19:43 PST --- Has this been verified to be only for D1? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12173] New: Optional start value for std.algorithm.sum
https://d.puremagic.com/issues/show_bug.cgi?id=12173
Summary: Optional start value for std.algorithm.sum
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-02-15 02:29:57 PST ---
The built-in Python sum() function supports a second optional argument that is
the start, it's useful when you want to sum an iterable of values starting from
a seed of another type (of different from zero):
sum([1, 2, 3])
6
sum([1, 2, 3], 2)
8
sum([1, 2, 3], 0.0)
6.0
sum([[1, 2], [3]], [])
[1, 2, 3]
This shows one use case for the same functionality in D:
import std.algorithm: sum, reduce;
import std.functional: curry;
struct Foo {
ubyte x;
alias x this;
}
alias mySum = curry!(reduce!q{a + b}, 0);
void main() {
Foo[] arr;
arr.mySum;// OK
arr.sum; // Error
//arr.sum(0); // Not supported
}
dmd 2.065beta3 gives:
..\dmd2\src\phobos\std\algorithm.d(1087,19): Error: cannot implicitly convert
expression (0) of type int to Foo
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
https://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #28 from bearophile_h...@eml.cc 2014-02-15 02:35:00 PST --- See also Issue 12173 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2776] pragma(lib, does not work when used in headers
https://d.puremagic.com/issues/show_bug.cgi?id=2776 --- Comment #8 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 02:44:31 PST --- (In reply to comment #7) Has this been verified to be only for D1? Not yet. But Walter is only converting the tags from D1.x to D1, and D2.x to D2. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12175] New: More efficient very common case for std.algorithm.sum
https://d.puremagic.com/issues/show_bug.cgi?id=12175
Summary: More efficient very common case for std.algorithm.sum
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-02-15 02:53:30 PST ---
The most common code path of std.algorithm.sum contains:
+Result seed = 0;
+return reduce!a + b(seed, r);
I suggest to add a static if that tests if the input is an array (or a random
access range) and in such case instead of reduce to use a more efficient loop
like this:
immutable lenR = r.length;
for (int i = 2; i lenR; i += 2) {
total1 += r[i];
total2 += r[i + 1];
}
return total1 + total2;
This is more efficient on most modern CPUs.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
https://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #30 from bearophile_h...@eml.cc 2014-02-15 02:53:59 PST --- See also Issue 12175 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12165] std.file.rmdirRecurse can't delete symbolic links or directory junctions
https://d.puremagic.com/issues/show_bug.cgi?id=12165 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2776] pragma(lib, does not work when used in headers
https://d.puremagic.com/issues/show_bug.cgi?id=2776 --- Comment #9 from Jacob Carlborg d...@me.com 2014-02-15 02:57:36 PST --- (In reply to comment #8) Not yet. But Walter is only converting the tags from D1.x to D1, and D2.x to D2. I see. But why not set it to D1 D2 when it's uncertain? Unless it's obvious it can only be for one version. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4725] std.algorithm.sum()
https://d.puremagic.com/issues/show_bug.cgi?id=4725 --- Comment #31 from bearophile_h...@eml.cc 2014-02-15 03:12:07 PST --- See also Issue 12176 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12176] New: Possible std.algorithm.sum optimization for short fixed-size arrays
https://d.puremagic.com/issues/show_bug.cgi?id=12176
Summary: Possible std.algorithm.sum optimization for short
fixed-size arrays
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-02-15 03:11:41 PST ---
I suggest to modify std.algorithm.sum (to add an overload) to let it accept
fixed-sized arrays too, and then add a specialization for short fixed-sized
arrays like:
int[3] a = [10, 20, 30];
immutable tot = a.sum;
This expands the places where you are willing to use sum() because with such
specialization a normal D compiler is able to produce inlined loop-free asm
code similar to writing down a manual sum of the array items:
immutable tot = a[0] + a[1] + a[2];
Generic library code should not be slower than built-in features, where
possible, and short fixed-sized arrays are not uncommon in high performance
code (and currently DMD doesn't inline code containing a loop. And sometimes
even with LDC2 loops are not unrolled if their size is a run-time value. To
unroll them it should inline the function and then see that the run-time length
is actually a compile-time one).
If you know at compile-time the length of an array, this is precious
information, and it's bad to just throw such information away, especially when
such length is small (when the length is large it makes no difference).
This specialization should be present only for small arrays (like Length = 5).
For the other cases and to reduce template bloat the sum() specialized on
fixed-sized arrays should just call (with a static if) the normal sum for
dynamic arrays with a slicing:
auto sum(size_t N)(T[N] arr) {
static if (N 6) {
// short-case implementation here ...
} else {
return sum(arr[]);
}
}
Using the sum() code from std.algorithm, this main() gets compiled by the
latest ldc2:
int main() {
int[3] a = [10, 20, 30];
return cast(int)a[].sum;
}
As (-O -release -inline -noboundscheck -output-s):
__Dmain:
pushl %ebp
pushl %ebx
pushl %edi
pushl %esi
subl$28, %esp
movl$10, 16(%esp)
movl$20, 20(%esp)
movl$30, 24(%esp)
leal16(%esp), %edi
movl%edi, 4(%esp)
movl$3, (%esp)
xorl%esi, %esi
calll __D3std5array12__T5emptyTiZ5emptyFNaNbNdNfxAiZb
subl$8, %esp
testb $1, %al
jne LBB0_3
movl$3, %eax
movl%edi, %ecx
leal20(%esp), %ebx
xorl%esi, %esi
movl$2, %ebp
xorl%edi, %edi
.align 16, 0x90
LBB0_2:
movl%ecx, 4(%esp)
movl%eax, (%esp)
calll __D3std5array12__T5frontTiZ5frontFNaNbNcNdNfAiZi
subl$8, %esp
movl(%eax), %eax
movl%eax, %ecx
sarl$31, %ecx
addl%eax, %esi
adcl%ecx, %edi
movl%ebx, 8(%esp)
movl%ebp, 12(%esp)
movl%ebx, 4(%esp)
movl%ebp, (%esp)
calll __D3std5array12__T5emptyTiZ5emptyFNaNbNdNfxAiZb
subl$8, %esp
movl8(%esp), %ecx
decl%ebp
addl$4, %ebx
testb $1, %al
movl12(%esp), %eax
je LBB0_2
LBB0_3:
movl%esi, %eax
addl$28, %esp
popl%esi
popl%edi
popl%ebx
popl%ebp
ret
The idea proposed here is just an optimization, so in theory a sufficiently
smart compiler should not need it.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2776] pragma(lib, does not work when used in headers
https://d.puremagic.com/issues/show_bug.cgi?id=2776 --- Comment #10 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 03:11:26 PST --- (In reply to comment #9) (In reply to comment #8) Not yet. But Walter is only converting the tags from D1.x to D1, and D2.x to D2. I see. But why not set it to D1 D2 when it's uncertain? Unless it's obvious it can only be for one version. Because there are some bugs that are marked D1 D2 which /are/ actually both D1 and D2 bugs. We shouldn't introduce false-positives. Anyway depending on arbitrary meaning for these tags is probably a bad idea, why not introduce a new keyword verify_D2 or something like that for bugs that should be checked whether they might also apply to D2? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7666] A function to reverse the items of a tuple
https://d.puremagic.com/issues/show_bug.cgi?id=7666 --- Comment #13 from bearophile_h...@eml.cc 2014-02-15 03:21:05 PST --- The presence of this function solves the problem of choosing what's the right API for the Phobos-defined array.reverse: for API uniformity is should be like this one, so array.reverse should reverse the items in-place (unlike this Tuple.reverse) and return the reversed items, to be used in UFCS chains. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10318] Built-in array sort usage warning, then deprecation, and finally removal
https://d.puremagic.com/issues/show_bug.cgi?id=10318 --- Comment #9 from bearophile_h...@eml.cc 2014-02-15 03:24:26 PST --- Regarding the API of the Phobos-defined array.reverse see: https://d.puremagic.com/issues/show_bug.cgi?id=7666#c13 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12177] New: inout(Cycle!(string[2])) implicit cast problem
https://d.puremagic.com/issues/show_bug.cgi?id=12177
Summary: inout(Cycle!(string[2])) implicit cast problem
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-02-15 03:32:49 PST ---
I think this used to work until recently:
void main() {
import std.range;
foreach (s; recurrence!q{a[n - 1] ~ a[n - 2]}(1, 0)) {}
}
With DMD 2.065beta3 gives:
..\dmd2\src\phobos\std\range.d(4424,21): Error: cannot implicitly convert
expression ((nothrow Cycle!(string[2]) __ctmp1475 = 0;
, __ctmp1475).this(*cast(string[2]*)this._ptr, this._index + i)) of type
Cycle!(string[2]) to inout(Cycle!(string[2]))
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2776] pragma(lib, does not work when used in headers
https://d.puremagic.com/issues/show_bug.cgi?id=2776 --- Comment #11 from Jacob Carlborg d...@me.com 2014-02-15 03:30:32 PST --- (In reply to comment #10) Because there are some bugs that are marked D1 D2 which /are/ actually both D1 and D2 bugs. We shouldn't introduce false-positives. Then setting it to D1 would not be correct either. Anyway depending on arbitrary meaning for these tags is probably a bad idea, why not introduce a new keyword verify_D2 or something like that for bugs that should be checked whether they might also apply to D2? Sure, there's already a version unspecified. I'm pretty certain this particular bug applies both for D1 and D2, that's why I reacted. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2776] pragma(lib, does not work when used in headers
https://d.puremagic.com/issues/show_bug.cgi?id=2776 --- Comment #12 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 03:33:51 PST --- (In reply to comment #11) (In reply to comment #10) Because there are some bugs that are marked D1 D2 which /are/ actually both D1 and D2 bugs. We shouldn't introduce false-positives. Then setting it to D1 would not be correct either. But it already was, he just changed D.X into D1. Or is that still an issue? Sure, there's already a version unspecified. I'm pretty certain this particular bug applies both for D1 and D2, that's why I reacted. Well either way we have a lot of work to do testing and verifying these bugs. :) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12178] New: ddoc arbitrarily injects tabs instead of spaces in the output
https://d.puremagic.com/issues/show_bug.cgi?id=12178 Summary: ddoc arbitrarily injects tabs instead of spaces in the output Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: ddoc Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 03:49:32 PST --- Created an attachment (id=1324) image Note the space before the first opt, and before and after the second opt, it's a tab instead of a space. It makes the docs look long and ugly. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2776] pragma(lib, does not work when used in headers
https://d.puremagic.com/issues/show_bug.cgi?id=2776 --- Comment #13 from Jacob Carlborg d...@me.com 2014-02-15 04:08:38 PST --- (In reply to comment #12) But it already was, he just changed D.X into D1. Just because it's set to DMD 1.x doesn't mean it's only for D1. The creator of the bug report could have set it to latest versions available when it was created. Or is that still an issue? I'm pretty certain it is. I have not heard of any changes related to pragma(lib). Well either way we have a lot of work to do testing and verifying these bugs. :) Absolutely. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11945] LockingTextWriter fails with repeat
https://d.puremagic.com/issues/show_bug.cgi?id=11945 --- Comment #2 from github-bugzi...@puremagic.com 2014-02-15 04:47:57 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/5dbb6539e3bce241ccea886ebef9ad1f4e201020 Fix Issue 11945 - LockingTextWriter.put The function just had sloppy constraints while assuming it was a string. This fixes it up and adds some basic unit tests. https://d.puremagic.com/issues/show_bug.cgi?id=11945 https://github.com/D-Programming-Language/phobos/commit/2b558a95f21cfd6a3b6db7d45916a11a8a828798 Merge pull request #1887 from Poita/bug11945 Fix Issue 11945 - LockingTextWriter.put -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11903] Internal error: backend/cgcs.c 351
https://d.puremagic.com/issues/show_bug.cgi?id=11903 Damian damian...@hotmail.co.uk changed: What|Removed |Added CC||damian...@hotmail.co.uk --- Comment #3 from Damian damian...@hotmail.co.uk 2014-02-15 04:49:45 PST --- Also happens with LDC 2.063.2 (0.12.0) 0 ldc20x01014882 llvm::sys::PrintStackTrace(_IO_FILE*) + 34 1 ldc20x010162ea 2 libpthread.so.0 0x404491e0 3 ldc20x00635596 DtoBitCast(llvm::Value*, llvm::Type*, char const*) + 22 4 ldc20x006e473c DtoCatAssignElement(Loc, Type*, DValue*, Expression*) + 220 5 ldc20x0065283b CatAssignExp::toElem(IRState*) + 235 6 ldc20x0065acc0 Expression::toElemDtor(IRState*) + 576 7 ldc20x0067ffeb ExpStatement::toIR(IRState*) + 91 8 ldc20x0067feaf CompoundStatement::toIR(IRState*) + 95 9 ldc20x0067feaf CompoundStatement::toIR(IRState*) + 95 10 ldc20x006162e1 DtoDefineFunction(FuncDeclaration*) + 1905 11 ldc20x006683cc Module::genLLVMModule(llvm::LLVMContext) + 716 12 ldc20x0056c582 main + 5138 13 libc.so.6 0x41299a15 __libc_start_main + 245 14 ldc20x00555d69 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11945] LockingTextWriter fails with repeat
https://d.puremagic.com/issues/show_bug.cgi?id=11945 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12169] sum(int[]) should return a int
https://d.puremagic.com/issues/show_bug.cgi?id=12169 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m AssignedTo|nob...@puremagic.com|and...@erdani.com --- Comment #1 from Peter Alexander peter.alexander...@gmail.com 2014-02-15 05:49:52 PST --- This is by design in the code, presumably to avoid overflow (which you are usually so concerned about, what changed?) I actually agree with you though. I'd expect sum!(int[]) to return int. In general, I'd expect sum!(T[]) to return typeof(T.init + T.init), and respect the language integral promotions. A nice compromise might be to adjust the API: int[] xs; int sum1 = sum(xs); long sum2 = sum!long(xs); That way, you can specify what type to return. This also solves the problem of potential overflows with longs (just specify ReturnType = BigInt). I'll assign this to Andrei for his thoughts. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12170] sum(double[]) is not pure
https://d.puremagic.com/issues/show_bug.cgi?id=12170 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m OS/Version|Windows |All --- Comment #1 from Peter Alexander peter.alexander...@gmail.com 2014-02-15 06:09:57 PST --- The problem is this: Cyclic functions (i.e. functions that wind up directly or indirectly calling themselves) are inferred as being impure, throwing, and @system. http://dlang.org/function.html sum uses a recursive algorithm for summing floating point ranges for extra accuracy, so its purity is not inferred. It cannot just be marked as pure because the range operations it uses may not be pure. I'm not sure why that cyclic function restriction exists. I think it should be possible to infer these attributes on recursive functions. I'll have a think. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12169] sum(int[]) should return a int
https://d.puremagic.com/issues/show_bug.cgi?id=12169 --- Comment #2 from Andrei Alexandrescu and...@erdani.com 2014-02-15 06:15:26 PST --- If sum returned int for ranges of int, it would be 100% identical to std.algorithm.reduce. It's worth returning a 64-bit quantity because (a) 64-bit summing is about as fast as 32-bit summing, (b) the result can be cast to int if needed. I propose we close this. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12173] Optional start value for std.algorithm.sum
https://d.puremagic.com/issues/show_bug.cgi?id=12173 Andrei Alexandrescu and...@erdani.com changed: What|Removed |Added CC||and...@erdani.com --- Comment #1 from Andrei Alexandrescu and...@erdani.com 2014-02-15 06:20:03 PST --- Doesn't an add outside the sum call do the same? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12173] Optional start value for std.algorithm.sum
https://d.puremagic.com/issues/show_bug.cgi?id=12173 --- Comment #2 from bearophile_h...@eml.cc 2014-02-15 06:29:14 PST --- (In reply to comment #1) Doesn't an add outside the sum call do the same? An add outside the sum doesn't solve the problem with Foo. Another example: long[] data = [...]; immutable total = data.sum(0.BigInt); If the longs are large enough this gives the correct result, unlike summing with longs. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12169] sum(int[]) should return a int
https://d.puremagic.com/issues/show_bug.cgi?id=12169 --- Comment #3 from bearophile_h...@eml.cc 2014-02-15 06:32:29 PST --- (In reply to comment #1) This is by design in the code, presumably to avoid overflow (which you are usually so concerned about, what changed?) I have tens of usages of sum in my code and no case I need a long result. So the Phobos sum halves my usability. And I need to keep my own sum() around. I actually agree with you though. I'd expect sum!(int[]) to return int. In general, I'd expect sum!(T[]) to return typeof(T.init + T.init), and respect the language integral promotions. Right. A nice compromise might be to adjust the API: int[] xs; int sum1 = sum(xs); long sum2 = sum!long(xs); That way, you can specify what type to return. This also solves the problem of potential overflows with longs (just specify ReturnType = BigInt). This is OK, but an alternative (and in my opinion better) solution is in Issue 12173: long sum2 = xs.sum(0L); -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12169] sum(int[]) should return a int
https://d.puremagic.com/issues/show_bug.cgi?id=12169 --- Comment #4 from bearophile_h...@eml.cc 2014-02-15 06:38:04 PST --- (In reply to comment #2) If sum returned int for ranges of int, it would be 100% identical to std.algorithm.reduce. If it's equal to what reduce does, it gives less surprises to the programmer. I am sure in Haskell you don't see a sum to act differently from reduce. One is defined on the other, for uniformity, simplicity and minimize surprises. Also what do you want sum(long[]) to return on default? A cent perhaps? It's worth returning a 64-bit quantity because (a) 64-bit summing is about as fast as 32-bit summing, (b) the result can be cast to int if needed. I am not so fond of casts. What if later I change the code and I am now summing floats instead? The cast(int) will remove the floating point part :-) I propose we close this. Let's hear what others think first :-) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12170] sum(double[]) is not pure nothrow
https://d.puremagic.com/issues/show_bug.cgi?id=12170
bearophile_h...@eml.cc changed:
What|Removed |Added
Summary|sum(double[]) is not pure |sum(double[]) is not pure
||nothrow
--- Comment #2 from bearophile_h...@eml.cc 2014-02-15 06:43:26 PST ---
Yes, the same happens with nothrow:
void main() nothrow {
import std.algorithm: sum;
[1.0].sum;
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12179] New: [ICE](e2ir.c 1861) with array operation
https://d.puremagic.com/issues/show_bug.cgi?id=12179
Summary: [ICE](e2ir.c 1861) with array operation
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-02-15 06:46:57 PST ---
void foo(int[]) {}
void main() {
int[1] a;
(a[] * a[]).foo;
}
dmd 2.065beta3 gives:
Internal error: e2ir.c 1861
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12170] sum(double[]) is not pure nothrow
https://d.puremagic.com/issues/show_bug.cgi?id=12170 --- Comment #3 from bearophile_h...@eml.cc 2014-02-15 06:49:39 PST --- (In reply to comment #1) The problem is this: Cyclic functions (i.e. functions that wind up directly or indirectly calling themselves) are inferred as being impure, throwing, and @system. Until that compiler limitation is lifted, a solution is to convert the recursive algorithm of sum() in an iterative one. Because sum() is something you often want to use in pure nothrow functions. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9477] String (and array) comparisons are needlessly very slow
https://d.puremagic.com/issues/show_bug.cgi?id=9477 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Resolution|WORKSFORME |FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12151] Diagnostic for .dup/.idup should emit code before the internal rewrite
https://d.puremagic.com/issues/show_bug.cgi?id=12151 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2014-02-16 02:06:52 EST --- Along with a billion other similar rewrites. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12154] Address of a member function doesn't tell about this - breaks std.concurrency
https://d.puremagic.com/issues/show_bug.cgi?id=12154 yebblies yebbl...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||yebbl...@gmail.com Resolution||DUPLICATE --- Comment #2 from yebblies yebbl...@gmail.com 2014-02-16 02:18:59 EST --- This is issue 3720, the delegate one is issue 2672. I'm starting to think `Type.nonstaticfunc` should only be valid inside typeof, and otherwise give a 'need this to access ...' error. *** This issue has been marked as a duplicate of issue 3720 *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3720] Taking address of member functions possible without an instance
https://d.puremagic.com/issues/show_bug.cgi?id=3720 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||destructiona...@gmail.com --- Comment #7 from yebblies yebbl...@gmail.com 2014-02-16 02:18:59 EST --- *** Issue 12154 has been marked as a duplicate of this issue. *** -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12153] Ternary operator on static array lvalues creates copy
https://d.puremagic.com/issues/show_bug.cgi?id=12153 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2014-02-16 02:21:21 EST --- Sigh, the backend sees int[1] i = 0; int[1] j = 0; bool b = true; (b ? i : j)[] = [4]; assert(i == [4]); return 0; Another bug caused by lowering static array ops to slice ops. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12155] Better line and column numbers for missing semicolon
https://d.puremagic.com/issues/show_bug.cgi?id=12155 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #2 from yebblies yebbl...@gmail.com 2014-02-16 02:25:04 EST --- Bearophile - the only person around who constantly re-reports their own bugs. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9477] String (and array) comparisons are needlessly very slow
https://d.puremagic.com/issues/show_bug.cgi?id=9477 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-15 17:44:19 EET --- @Daniel: I thought we need to close bugs that were not fixed in the current development iteration as WORKSFORME? Otherwise they'll end up in this iteration's changelog. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12148] std.uuid.parseUUID should document that it changes lvalue input data
https://d.puremagic.com/issues/show_bug.cgi?id=12148 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com Summary|The function|std.uuid.parseUUID should |std.uuid.parseUUID changes |document that it changes |an input data |lvalue input data --- Comment #4 from yebblies yebbl...@gmail.com 2014-02-16 02:47:35 EST --- This is working as designed (similar to the std.conv.parse functions) although the documentation does not mention this. For a non-consuming parser for exact strings, use the constructor of UUID. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9477] String (and array) comparisons are needlessly very slow
https://d.puremagic.com/issues/show_bug.cgi?id=9477 --- Comment #5 from yebblies yebbl...@gmail.com 2014-02-16 02:56:04 EST --- (In reply to comment #4) @Daniel: I thought we need to close bugs that were not fixed in the current development iteration as WORKSFORME? Otherwise they'll end up in this iteration's changelog. No, WORKSFORME is for bugs with an unknown fix, such as ones that are probably a duplicate of another bug. This should be in the changelog, and better in the wrong version than not at all. Basically, keeping the bug tracker correct should be preferred over twisting it to fix the changelog, as this is the real history. https://d.puremagic.com/issues/page.cgi?id=fields.html#status -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12155] Better line and column numbers for missing semicolon
https://d.puremagic.com/issues/show_bug.cgi?id=12155 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 07:55:14 PST --- (In reply to comment #2) Bearophile - the only person around who constantly re-reports their own bugs. So much so that I have a special entry for his bugs in my speed dial in my browser. :P -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9477] String (and array) comparisons are needlessly very slow
https://d.puremagic.com/issues/show_bug.cgi?id=9477 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #6 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 07:59:53 PST --- (In reply to comment #5) (In reply to comment #4) @Daniel: I thought we need to close bugs that were not fixed in the current development iteration as WORKSFORME? Otherwise they'll end up in this iteration's changelog. No, WORKSFORME is for bugs with an unknown fix, such as ones that are probably a duplicate of another bug. This should be in the changelog, and better in the wrong version than not at all. It's not that hard to strip this out of the changelog by hand. It would be good if it was automatic, e.g. if the changelog tool would go through all bugzilla issues and then search whether a commit that fixed the issue (it would have to grep github-bugzi...@puremagic.com's comments) is located in some older tagged branch. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12163] pdb debugging (win64): stepping loops points to incorrect lines
https://d.puremagic.com/issues/show_bug.cgi?id=12163 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #7 from yebblies yebbl...@gmail.com 2014-02-16 03:04:14 EST --- (In reply to comment #6) It's obvious that DMD already does have a moment where it intends to step to the 'end of the loop cycle', except rather than pointing to the '}', it incorrectly points to the last significant line in the code, no matter how deeply nested it happens to be. Yeah, it simply doesn't know where the end of the loop is. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12164] Function returning ptrdiff_t.min in 64-bit returning 0 when -O is set.
https://d.puremagic.com/issues/show_bug.cgi?id=12164 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2014-02-16 03:05:08 EST --- Wrong code, yummy! -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12177] inout(Cycle!(string[2])) implicit cast problem
https://d.puremagic.com/issues/show_bug.cgi?id=12177 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #1 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-15 19:22:51 EET --- Introduced in https://github.com/D-Programming-Language/dmd/pull/3085 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12167] GIT HEAD: AAs are broken
https://d.puremagic.com/issues/show_bug.cgi?id=12167
Vladimir Panteleev thecybersha...@gmail.com changed:
What|Removed |Added
CC||thecybersha...@gmail.com
--- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-15
19:38:28 EET ---
(In reply to comment #0)
Also it rejects previously valid code:
class A {}
immutable A[short] table;
auto a = table.get(10, null);
This is the only example that I succeeded to compile with DMD 2.064.2.
This example was broken in these pull requests:
https://github.com/D-Programming-Language/dmd/pull/2856
https://github.com/D-Programming-Language/druntime/pull/668
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12167] GIT HEAD: AAs are broken
https://d.puremagic.com/issues/show_bug.cgi?id=12167 --- Comment #3 from Temtaime temta...@gmail.com 2014-02-15 09:42:14 PST --- http://dpaste.dzfl.pl/9c0ffd7fcadb All my examples previously worked. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12167] GIT HEAD: AAs are broken
https://d.puremagic.com/issues/show_bug.cgi?id=12167 --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-15 19:46:50 EET --- Sorry about that. Didn't look at the code too closely, didn't realize it contained statements that needed to be wrapped in functions. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12167] GIT HEAD: AAs are broken
https://d.puremagic.com/issues/show_bug.cgi?id=12167 --- Comment #5 from Temtaime temta...@gmail.com 2014-02-15 09:57:44 PST --- Do not sorry :) It's my mistake i had to do it by myself -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12179] [ICE](e2ir.c 1861) with array operation
https://d.puremagic.com/issues/show_bug.cgi?id=12179 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 11:05:20 PST --- Used to be: Error: Array operation a[] * a[] not implemented So I guess this is a diagnostic regression. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7654] Direct using of Rebindable!T doesn't work
https://d.puremagic.com/issues/show_bug.cgi?id=7654 --- Comment #2 from github-bugzi...@puremagic.com 2014-02-15 11:06:46 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/c9fe9679d43de8b960bb0bfcb208637dc28e0452 Fix Issue 7654 - Fix Rebindable of narrow strings. `Rebindable!(const(T)[])` should be `T[]`, but `Rebindable` was using `ElementType` instead of `ElementEncodingType`, which would result in `dchar[]` for narrow strings. This pull fixes this simple mistake. https://d.puremagic.com/issues/show_bug.cgi?id=7654 https://github.com/D-Programming-Language/phobos/commit/a35a00efb9171297e3119849bb77d2b9a46717df Merge pull request #1941 from Poita/bug7654 Fix Issue 7654 - Fix Rebindable of narrow strings. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7654] Direct using of Rebindable!T doesn't work
https://d.puremagic.com/issues/show_bug.cgi?id=7654 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||peter.alexander...@gmail.co ||m Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12046] Rebindable supports arrays
https://d.puremagic.com/issues/show_bug.cgi?id=12046 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #4 from Peter Alexander peter.alexander...@gmail.com 2014-02-15 11:53:05 PST --- https://github.com/D-Programming-Language/phobos/pull/1943 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
https://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #75 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-15 22:17:15 EET --- (In reply to comment #63) So we have stack traces on all platforms by now, can I close the bug? What about line numbers? I think we only have them on Win64. Regarding DWARF processing, it shouldn't be too hard. DWARF uses a weird state machine for efficient representation of file/line information. Doable but not trivial. But we could also dynamically load libdw.so from elfutils if it's installed similarly to how we load dbghelp.dll on Windows. It's GPL just like binutils. IANAL, but I'm not sure about dynamically loading GPL libs. I know the GPL forbids redistribution of any programs that include the library... Doesn't that mean that it would make it impossible for e.g. Linux distributions to distribute non-GPL D software together with the library? https://github.com/bombela/backward-cpp This seems to only support binutils and elfutils, both of which are GPL. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
https://d.puremagic.com/issues/show_bug.cgi?id=1001
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #76 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15
12:23:39 PST ---
(In reply to comment #64)
on Windows 64 bit a executable still crashes silently when a access violation
occures. At least with 2.064.2
Code used to test:
import core.stdc.stdio;
void test()
{
int* i;
*i = 5;
}
void main(string[] args)
{
test();
printf(done\n);
}
I can't reproduce this on Win7 x64 with 2.064. Here's the results for me:
$ dmd
DMD32 D Compiler v2.064
$ dmd -run test.d
object.Error: Access Violation
0x00402012 in __xc_a
0x004022FF in __xi_a
0x00402217 in __xc_z
0x00402047 in __xc_a
0x75CC3677 in BaseThreadInitThunk
0x77859D72 in __RtlUserThreadStart
0x77859D45 in _RtlUserThreadStart
$ dmd -g -run test.d
object.Error: Access Violation
0x00402019 in void test.test() at C:\dev\code\d_code\test.d(6)
0x0040202C in _Dmain at C:\dev\code\d_code\test.d(12)
0x0040233C in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll().void __lambda1()
0x0040230F in void rt.dmain2._d_run_main(int, char**, extern (C) int
function(char[][])*).runAll()
0x00402227 in _d_run_main
0x00402054 in main
0x004140A9 in mainCRTStartup
0x75CC3677 in BaseThreadInitThunk
0x77859D72 in __RtlUserThreadStart
0x77859D45 in _RtlUserThreadStart
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
https://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #78 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-15 22:31:49 EET --- (In reply to comment #76) I can't reproduce this on Win7 x64 with 2.064. Here's the results for me: The problem applies to 64-bit programs. I can reproduce it with -m64. (In reply to comment #75) It's GPL just like binutils. IANAL, but I'm not sure about dynamically loading GPL libs. I know the GPL forbids redistribution of any programs that include the library... Doesn't that mean that it would make it impossible for e.g. Linux distributions to distribute non-GPL D software together with the library? Just found this: http://www.gnu.org/licenses/gpl-faq.html#IfLibraryIsGPL Quoting: Q: If a library is released under the GPL (not the LGPL), does that mean that any software which uses it has to be under the GPL or a GPL-compatible license? A: Yes, because the software as it is actually run includes the library. So I guess that gives us a definitive answer. We CANNOT use binutils or elfutils, so libdw and libbfd are out of the question. From the discussed options, that leaves FreeBSD's Elftoolchain, integrating with addr2line, or our own DWARF/ELF parser. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
https://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #77 from Benjamin Thaut c...@benjamin-thaut.de 2014-02-15 12:31:09 PST --- @Andrej Mitrovic You forgott the -m64 switch in your test. You are testing 32-bit binaries. The problem is not the 64 bit operating system it is the 64-bit executable, as 64 bit executables do not implement SEH. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1001] print stack trace (in debug mode) when program die
https://d.puremagic.com/issues/show_bug.cgi?id=1001 --- Comment #79 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-02-15 12:50:07 PST --- (In reply to comment #77) @Andrej Mitrovic You forgott the -m64 switch in your test. You are testing 32-bit binaries. My bad. It's a huge thread and I didn't notice this. I can now confirm your test results with -m64. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3830] opCmp among variant arrays
https://d.puremagic.com/issues/show_bug.cgi?id=3830 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #3 from Peter Alexander peter.alexander...@gmail.com 2014-02-15 13:01:25 PST --- What should this do? auto a1 = variantArray(foo); auto a2 = variantArray(10); assert(a1 a2); Throw a type mismatch exception? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3794] Phobos' socket.receive should assert on the length of the target array
https://d.puremagic.com/issues/show_bug.cgi?id=3794 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added CC||peter.alexander...@gmail.co ||m --- Comment #2 from Peter Alexander peter.alexander...@gmail.com 2014-02-15 13:09:50 PST --- I propose we close this as WONTFIX. As Vladimir says, the function handles it safely, and there may be code out there relying on this. If there are no objections within a week, I'll close it. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 516] Mutually calling constructors allowed
https://d.puremagic.com/issues/show_bug.cgi?id=516 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Version|0.174 |D1 --- Comment #9 from Walter Bright bugzi...@digitalmars.com 2012-01-21 02:16:40 PST --- https://github.com/D-Programming-Language/d-programming-language.org/commit/d26103e11b8af546e4bfac71c412a0ecf02aac5d -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12046] Rebindable supports arrays
https://d.puremagic.com/issues/show_bug.cgi?id=12046 --- Comment #5 from github-bugzi...@puremagic.com 2014-02-15 14:01:15 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/f8aa638c5a78401006784b2b9f7ad456bca1b3dc Fix Issue 12046 - Disallow Rebindable!(T[N]) https://d.puremagic.com/issues/show_bug.cgi?id=12046 https://github.com/D-Programming-Language/phobos/commit/ae4678e2bb6baa61d5529d447ce4b5eca37ad7b4 Merge pull request #1943 from Poita/bug12046 Fix Issue 12046 - Disallow Rebindable!(T[N]) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12046] Rebindable supports arrays
https://d.puremagic.com/issues/show_bug.cgi?id=12046 Peter Alexander peter.alexander...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7069] Variant Doesn't Handle Const or Immutable Contents
https://d.puremagic.com/issues/show_bug.cgi?id=7069
Kapps opantm2+db...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||opantm2+db...@gmail.com
Resolution||FIXED
--- Comment #3 from Kapps opantm2+db...@gmail.com 2014-02-15 14:21:53 PST ---
This appears to have been fixed in git master:
https://github.com/D-Programming-Language/phobos/commit/6e7eabbd42a7f2e3e555081e1b17893c3c18b6f8
import std.variant, std.stdio;
class Bob {}
void main() {
immutable(Bob) bob = new immutable(Bob)();
writeln(cast(void*)bob);
Variant v = bob;
immutable(Bob) bob2 = v.get!(immutable(Bob))();
writeln(cast(void*)bob2);
}
Prints out
1091E4FF0
1091E4FF0
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11110] Variant.convertsTo doesn't work like isImplicitlyConvertible
https://d.puremagic.com/issues/show_bug.cgi?id=0 Kapps opantm2+db...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||opantm2+db...@gmail.com Resolution||FIXED --- Comment #2 from Kapps opantm2+db...@gmail.com 2014-02-15 14:36:28 PST --- Works in git master. I think https://github.com/D-Programming-Language/phobos/commit/6e7eabbd42a7f2e3e555081e1b17893c3c18b6f8 fixed this as well while fixing 7069. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10958] std.variant : Variant and Algebraic can't use a type when sizeof == 0
https://d.puremagic.com/issues/show_bug.cgi?id=10958 --- Comment #2 from github-bugzi...@puremagic.com 2014-02-15 14:55:44 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/b21c398ca2aad2934af4eec31dc4cf298d6b0b22 Fix issue 10958 - Variant fails to compile for types with sizeof == 0. https://github.com/D-Programming-Language/phobos/commit/adb9685694c63eae4b42bafa58e21ed69a42b148 Merge pull request #1936 from Kapps/fix10958 Fix issue 10958 - Variant fails to compile for types with sizeof == 0. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12046] Rebindable supports arrays
https://d.puremagic.com/issues/show_bug.cgi?id=12046 monarchdo...@gmail.com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #6 from monarchdo...@gmail.com 2014-02-15 14:55:36 PST --- 1943 fixed the *static* array issue (which was a bug, plain and simple). It still supports dynamic arrays, which I think it shouldn't. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3794] Phobos' socket.receive should assert on the length of the target array
https://d.puremagic.com/issues/show_bug.cgi?id=3794 Stanislav Blinov stanislav.bli...@gmail.com changed: What|Removed |Added CC||stanislav.bli...@gmail.com --- Comment #3 from Stanislav Blinov stanislav.bli...@gmail.com 2014-02-15 15:12:30 PST --- (In reply to comment #2) I propose we close this as WONTFIX. As Vladimir says, the function handles it safely, and there may be code out there relying on this. If there are no objections within a week, I'll close it. I agree. The function signature already indicates that no resizing is performed (it's void[], not ref void[]), so the assumption itself is unsubstantiated. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10958] std.variant : Variant and Algebraic can't use a type when sizeof == 0
https://d.puremagic.com/issues/show_bug.cgi?id=10958 Kapps opantm2+db...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12046] Rebindable supports arrays
https://d.puremagic.com/issues/show_bug.cgi?id=12046 --- Comment #7 from Peter Alexander peter.alexander...@gmail.com 2014-02-15 15:34:38 PST --- Sorry for closing, should have read the bug more carefully. However, I'm not sure what you expect to happen here. Rebindable has supported arrays for several years now. We can't just remove it. Removing it would making Rebindable a little more simple, and allows us to remove a few lines of code, but are there any other benefits? Is it worth potentially breaking someone's code, or introducing a slow deprecation process? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12121] atomicLoad!(MemoryOrder.acq) should not emit additional code on X86
https://d.puremagic.com/issues/show_bug.cgi?id=12121 --- Comment #3 from github-bugzi...@puremagic.com 2014-02-15 15:40:42 PST --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/391573925590cf042d1d10345b0ec39699ccd48a fix Issue 12121 - atomicLoad!(MemoryOrder.acq) doesn't require load barrier [Issue 12121 – atomicLoad!(MemoryOrder.acq) should not emit additional code on X86](https://d.puremagic.com/issues/show_bug.cgi?id=12121) https://github.com/D-Programming-Language/druntime/commit/9a8a09d6746181350021b06107515013ef2a25ce Merge pull request #723 from MartinNowak/fix12121 fix Issue 12121 - atomicLoad!(MemoryOrder.acq) doesn't require load barrier -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12121] atomicLoad!(MemoryOrder.acq) should not emit additional code on X86
https://d.puremagic.com/issues/show_bug.cgi?id=12121 Stanislav Blinov stanislav.bli...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12179] [ICE](e2ir.c 1861) with array operation
https://d.puremagic.com/issues/show_bug.cgi?id=12179 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-16 02:54:17 EET --- Introduced in https://github.com/D-Programming-Language/dmd/pull/2960 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7690] std.string.join of const string array too
https://d.puremagic.com/issues/show_bug.cgi?id=7690 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #4 from bearophile_h...@eml.cc 2014-02-15 17:31:43 PST --- Fixed: https://github.com/D-Programming-Language/phobos/pull/1865 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12051] Wrong code with ?: resulting in char on x86-64
https://d.puremagic.com/issues/show_bug.cgi?id=12051 --- Comment #6 from github-bugzi...@puremagic.com 2014-02-15 19:23:10 PST --- Commit pushed to 2.065 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/b1ba7340cf028a3fd9857de2980b6eb611c0caef Merge pull request #3182 from yebblies/issue12051 Issue 12051 - Wrong code with ?: resulting in char on x86-64 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12071] Algebraic won't take delegate returning structure
https://d.puremagic.com/issues/show_bug.cgi?id=12071 --- Comment #4 from github-bugzi...@puremagic.com 2014-02-15 19:23:10 PST --- Commit pushed to 2.065 at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/d430dd14d63c68aae3dae1fc0cacc4de264ff27a Merge pull request #1909 from 9rnsr/fix12071 [REG2.065a] Issue 12071 - Algebraic won't take delegate returning structure -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12167] GIT HEAD: AAs are broken
https://d.puremagic.com/issues/show_bug.cgi?id=12167 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #6 from yebblies yebbl...@gmail.com 2014-02-16 14:53:15 EST --- That's weird, it looks like the compiler is trying to tail-const the AA, badly. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12144] [REG DMD2.064] Unresolved xopEquals when referenced by dynamic array constructor
https://d.puremagic.com/issues/show_bug.cgi?id=12144 --- Comment #4 from github-bugzi...@puremagic.com 2014-02-15 20:47:27 PST --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/0cf5608cd9a0041e3c47290dd52f737b40fceabd fix Issue 12144 - Unresolved xopEquals when referenced by dynamic array constructor https://github.com/D-Programming-Language/dmd/commit/4f8919f100db6e40c30b6d3047e06486d0dd007d Merge pull request #3256 from 9rnsr/fix12144 [REG2.064] Issue 12144 - Unresolved xopEquals when referenced by dynamic array constructor -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12167] GIT HEAD: AAs are broken
https://d.puremagic.com/issues/show_bug.cgi?id=12167
--- Comment #7 from Kenji Hara k.hara...@gmail.com 2014-02-15 21:23:58 PST ---
This is one another regression caused by removing object.AssociativeArray.
struct S11 { int opCmp(T : typeof(this))(T) { return 0; } }
void main()
{
{ auto ti = typeid(int[S11]); }
}
This code compiles used to compile until 2.064, but in 2.065 development term,
it has been made disallowed by the fix for issue 11591.
But in git head, it does not cause error. I noticed the change during maintain
2.065 branch (Related PR:
https://github.com/D-Programming-Language/dmd/pull/3271).
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12144] [REG DMD2.064] Unresolved xopEquals when referenced by dynamic array constructor
https://d.puremagic.com/issues/show_bug.cgi?id=12144 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #5 from Kenji Hara k.hara...@gmail.com 2014-02-15 21:29:10 PST --- Merged pull request: https://github.com/D-Programming-Language/dmd/pull/3256 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12144] [REG DMD2.064] Unresolved xopEquals when referenced by dynamic array constructor
https://d.puremagic.com/issues/show_bug.cgi?id=12144 --- Comment #6 from github-bugzi...@puremagic.com 2014-02-15 22:03:43 PST --- Commits pushed to 2.065 at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ef0b1445ccb8492ec64d78da5583e0cbb380e15b Merge pull request #3256 from 9rnsr/fix12144 [REG2.064] Issue 12144 - Unresolved xopEquals when referenced by dynamic array constructor Conflicts: src/cast.c src/typinf.c Additional fix: src/expression.h https://github.com/D-Programming-Language/dmd/commit/2c3555e01458b2c15ab164f1dbc261002c9ec547 Fix up issue 12144 test case -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12046] Rebindable supports arrays
https://d.puremagic.com/issues/show_bug.cgi?id=12046 --- Comment #8 from monarchdo...@gmail.com 2014-02-15 23:28:28 PST --- (In reply to comment #7) However, I'm not sure what you expect to happen here. Rebindable has supported arrays for several years now. We can't just remove it. Removing it would making Rebindable a little more simple, and allows us to remove a few lines of code, but are there any other benefits? Is it worth potentially breaking someone's code, or introducing a slow deprecation process? I don't know what I expect to happen, nor what the best solution is, but there *is* something odd here, and that's why I filed the issue. As I said, it goes against what documentation says. I also find it *very* inconsistent that arrays are accepted, but not pointers nor AA's. Especially pointers, which are the closest things to classes. *I*'d introduce a slow deprecation process. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11282] std.process: add capability for two-way inter-process communication without deadlock
https://d.puremagic.com/issues/show_bug.cgi?id=11282 --- Comment #12 from Vladimir Panteleev thecybersha...@gmail.com 2014-02-16 09:34:33 EET --- Ping? Does that design satisfy your requirements? Can I (or someone else) go ahead with implementing it? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12137] [REG DMD2.065-b3] Huge decline in performance
https://d.puremagic.com/issues/show_bug.cgi?id=12137 Martin Nowak c...@dawg.eu changed: What|Removed |Added CC||c...@dawg.eu --- Comment #11 from Martin Nowak c...@dawg.eu 2014-02-15 23:33:26 PST --- From where do I get the correct snn.lib? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4417] uniform() doesn't check constness of RNG
https://d.puremagic.com/issues/show_bug.cgi?id=4417 --- Comment #2 from github-bugzi...@puremagic.com 2014-02-15 23:37:19 PST --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/26eecf465162ec60a8d7b595a1e72f9b226fb0ae Fix Issue 4417 - isUniformRNG constraints for std.random.uniform https://d.puremagic.com/issues/show_bug.cgi?id=4417 https://github.com/D-Programming-Language/phobos/commit/1a063adbd500b5a9ea1d2d4c31c964f792a53ae2 Merge pull request #1944 from Poita/bug4417 Fix Issue 4417 - isUniformRNG constraints for std.random.uniform -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
