[Issue 9924] Handy enum accessors
http://d.puremagic.com/issues/show_bug.cgi?id=9924 --- Comment #5 from Walter Bright 2013-04-11 19:47:44 PDT --- For similar reasons, I don't see a compelling case for nextMember or prevMember, either. I expect that an algorithm needing the next or previous member would be looping over EnumMembers!E[i] anyway. Such functions do not make code clearer, they obfuscate it behind trivia. The user wastes time wondering "should I use first(), or [0]? Why are there both? Is there a difference?" The documentation fills up with this pointless ephemera. A well designed interface should have a *minimum* of concepts and methods. They should ideally all be orthogonal, with zero overlap. I don't know Ada, but I suspect it has these methods because it does not have the [i] way of getting at enum members. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 259] Comparing signed to unsigned does not generate an error
http://d.puremagic.com/issues/show_bug.cgi?id=259
--- Comment #48 from Lionello Lunesu 2013-04-11
19:42:37 PDT ---
// For the record: my test cases. Will add/fix existing unittests as well.
import std.traits;
int i;
uint ui;
long l;
ulong ul;
// 0. same-signed-ness
static assert(__traits(compiles, ui>ul));
static assert(__traits(compiles, ul>ui));
static assert(__traits(compiles, i>l));
static assert(__traits(compiles, l>i));
static assert(__traits(compiles, 1>2));
static assert(!(1>2));
static assert(__traits(compiles, 2>1));
static assert(2>1);
// 1. sizeof(signed) > sizeof(unsigned)
static assert(__traits(compiles, l>ui));
static assert(__traits(compiles, ui>l));
static assert(__traits(compiles, -1L>2));
static assert(!(-1L>2));
static assert(__traits(compiles, 2>-1L));
static assert(2>-1L);
// 2. signed.min >= 0
static assert(__traits(compiles, ui>cast(int)2));
static assert(__traits(compiles, cast(int)2>ui));
static assert(__traits(compiles, ul>cast(int)2));
static assert(__traits(compiles, cast(int)2>ul));
// 3. unsigned.max < typeof(unsigned.max/2)
static assert(__traits(compiles, i>cast(uint)2));
static assert(__traits(compiles, cast(uint)2>i));
static assert(__traits(compiles, cast(int)-1>cast(uint)3));
static assert(__traits(compiles, cast(uint)3>cast(int)-1));
static assert(__traits(compiles, -1>2UL));
static assert(!(-1>2UL));
static assert(__traits(compiles, 2UL>-1));
static assert(2UL>-1);
// error
static assert(!__traits(compiles, ul>-2));
static assert(!__traits(compiles, -2>ul));
static assert(!__traits(compiles, i>ul));
static assert(!__traits(compiles, ul>i));
static assert(!__traits(compiles, l>ul));
static assert(!__traits(compiles, ul>l));
static assert(!__traits(compiles, i>ui));
static assert(!__traits(compiles, ui>i));
void main(){}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9924] Handy enum accessors
http://d.puremagic.com/issues/show_bug.cgi?id=9924 --- Comment #4 from Walter Bright 2013-04-11 19:37:02 PDT --- (In reply to comment #2) > But note FirstElement is present in Phobos, it's named std.array.front: front() is there to support ranges, it is not a shorthand for [0]. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 259] Comparing signed to unsigned does not generate an error
http://d.puremagic.com/issues/show_bug.cgi?id=259 --- Comment #47 from Lionello Lunesu 2013-04-11 19:24:53 PDT --- https://github.com/D-Programming-Language/dmd/pull/1889 There are many things silently(!) breaking, though, as some templates are not being chosen because of internal comparison errors. For example, FormatSpec.width and FormatSpec.precision are ints but often compared against array lengths (for padding and such). TBH, using negative width and precision to mean "argument index" is a hack and we'd be better off changing them to uint and use a flag for the "argument index" case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9924] Handy enum accessors
http://d.puremagic.com/issues/show_bug.cgi?id=9924
--- Comment #3 from bearophile_h...@eml.cc 2013-04-11 18:51:20 PDT ---
If you remove FirstMember and LastMember the whatBeats() function:
static Choice whatBeats(in Choice ch) /*pure nothrow*/ {
if (ch == LastMember!Choice)
return FirstMember!Choice;
else
return nextMember(ch);
}
Becomes:
static Choice whatBeats(in Choice ch) /*pure nothrow*/ {
if (ch == EnumMembers!Choice[$ - 1])
return EnumMembers!Choice[0];
else
return nextMember(ch);
}
It's more noisy, and visually it's a little less easy to tell it's correct.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9924] Handy enum accessors
http://d.puremagic.com/issues/show_bug.cgi?id=9924
--- Comment #2 from bearophile_h...@eml.cc 2013-04-11 18:22:16 PDT ---
(In reply to comment #1)
> I don't see much need for FirstMember and LastMember, just as I don't see a
> need for:
>
> E FirstElement(E)(E[] a) { return a[0]; }
>
> I believe such functions are trivia.
Maybe you are right, I am not sure.
But note FirstElement is present in Phobos, it's named std.array.front:
@property ref T front(T)(T[] a)
if (!isNarrowString!(T[]) && !is(T[] == void[]))
{
assert(a.length, "Attempting to fetch the front of an empty array of " ~
T.stringof);
return a[0];
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9924] Handy enum accessors
http://d.puremagic.com/issues/show_bug.cgi?id=9924
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #1 from Walter Bright 2013-04-11
18:04:42 PDT ---
I don't see much need for FirstMember and LastMember, just as I don't see a
need for:
E FirstElement(E)(E[] a) { return a[0]; }
I believe such functions are trivia.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9924] New: Handy enum accessors
http://d.puremagic.com/issues/show_bug.cgi?id=9924
Summary: Handy enum accessors
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 2013-04-11 17:20:49 PDT ---
To better use enums I suggest to add to Phobos four small templates/functions
like this (similar things are builtins in Ada):
import std.conv: text;
import std.traits: EnumMembers;
template FirstMember(E) if (is(E == enum)) {
enum FirstMember = EnumMembers!E[0];
}
template LastMember(E) if (is(E == enum)) {
enum LastMember = EnumMembers!E[$ - 1];
}
E predMember(E)(E e) /*pure nothrow*/ if (is(E == enum))
in {
assert(e != FirstMember!E);
} body {
switch (e) {
foreach (i, e2; EnumMembers!E[1 .. $])
mixin("case E." ~ text(cast(E)e2) ~ ": return E."
~ text(cast(E)(EnumMembers!E[i])) ~ ";");
default: assert(0);
}
}
E nextMember(E)(E e) /*pure nothrow*/ if (is(E == enum))
in {
assert(e != LastMember!E);
} body {
switch (e) {
foreach (i, e2; EnumMembers!E[0 .. $ - 1])
mixin("case E." ~ text(cast(E)e2) ~ ": return E."
~ text(cast(E)(EnumMembers!E[i + 1])) ~ ";");
default: assert(0);
}
}
void main() { // Demo ---
import std.stdio;
enum Choice { rock, paper, scissors }
static Choice whatBeats(in Choice ch) /*pure nothrow*/ {
if (ch == LastMember!Choice)
return FirstMember!Choice;
else
return nextMember(ch);
}
foreach (e; [EnumMembers!Choice])
writeln(e, " ", whatBeats(e));
writeln(predMember(Choice.paper));
writeln(predMember(Choice.scissors));
writeln(nextMember(Choice.rock));
writeln(nextMember(Choice.paper));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9922] Improve symbol emitting for templates for better separate compilation support
http://d.puremagic.com/issues/show_bug.cgi?id=9922 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #1 from Martin Nowak 2013-04-11 16:39:25 PDT --- (In reply to comment #0) > Most time it is just extra job for linker, but sometimes this results in nasty > bugs when resulting symbols are not weak ones. > I'd say this is a bug, any templated symbol must be weak. Do you have a test case for this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7044] Missing a way to control the order of arguments passed to the linker makes impossible to link some programs
http://d.puremagic.com/issues/show_bug.cgi?id=7044 Martin Nowak changed: What|Removed |Added CC||c...@dawg.eu --- Comment #10 from Martin Nowak 2013-04-11 16:18:03 PDT --- I think link flags should not be hardcoded in the compiler. They are platform dependent and belong into a configuration file so that package maintainers can easily patch them. I don't see why we need defaultlib/debuglib if one can specify link flags. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9923] New: [ICE] (interpret.c line 167) with countUntil on Typedef[]
http://d.puremagic.com/issues/show_bug.cgi?id=9923
Summary: [ICE] (interpret.c line 167) with countUntil on
Typedef[]
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-04-11 16:03:48 PDT ---
import std.algorithm: countUntil;
import std.typecons: Typedef;
alias Foo = Typedef!(const string);
immutable Foo[] bar = ["a", "b"];
void main() {
Foo a;
countUntil(bar, a);
}
DMD 2.063alpha gives:
Assertion failure: 'v->ctfeAdrOnStack >= 0 && v->ctfeAdrOnStack <
stackPointer()' on line 167 in file 'interpret.c'
Removing the const the compiler doesn't crash:
import std.algorithm: countUntil;
import std.typecons: Typedef;
alias Foo = Typedef!(string);
immutable Foo[] bar = ["a", "b"];
void main() {
Foo a;
countUntil(bar, a);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9866] movsxd not supported
http://d.puremagic.com/issues/show_bug.cgi?id=9866 --- Comment #1 from John Colvin 2013-04-11 23:27:05 BST --- Thanks Martin. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9866] movsxd not supported
http://d.puremagic.com/issues/show_bug.cgi?id=9866 John Colvin changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9920] [Optimizer] Use mul/imul for integer division by constant
http://d.puremagic.com/issues/show_bug.cgi?id=9920
--- Comment #5 from Dmitry Olshansky 2013-04-11
12:33:09 PDT ---
Another data point taken from issue 5607 on div/mod heavy program seems to
confirm my estimate of 3x+ speed difference with mul-trick applied.
The program is bound on div/mul operaiton so other differences of GCC vs DMC
codegen has little effect.
-
Timings, n = 100_000_000:
GCC: 3.13 s
DMD: 11.69 s
dmd -O -release -inline testd.d
gcc -O3 -s testc.c -o testc.exe
32 bit
GCC 4.5.2
DMD 2.052beta
-
// D2 code
import std.c.stdio: printf;
int main() {
uint total = 0;
uint i;
for (i = 0; i < 1; i++) {
uint n = i;
uint res = n % 10;
n /= 10;
while (n != 0) {
res = (n % 10) + (10 * res);
n /= 10;
}
total += res;
}
printf("%u\n", total); // 461784529
return 0;
}
-
// C code
#include "stdio.h"
typedef unsigned long uint;
int main() {
uint total = 0;
uint i;
for (i = 0; i < 1; i++) {
uint n = i;
uint res = n % 10;
n /= 10;
while (n != 0) {
res = (n % 10) + (10 * res);
n /= 10;
}
total += res;
}
printf("%u\n", total); // 461784529
return 0;
}
-
DMD inner loop:
L1C:leaEBX,[EBX*4][EBX]
movEAX,ESI
movECX,0Ah
xorEDX,EDX
addEBX,EBX
divECX
addEBX,EDX
test EAX,EAX
movESI,EAX
jneL1C
-
GCC inner loop:
L7:
movl%ecx, %eax
mull%esi
leal(%ebx,%ebx,4), %ebx
shrl$3, %edx
leal(%edx,%edx,4), %eax
addl%eax, %eax
subl%eax, %ecx
testl%edx, %edx
leal(%ecx,%ebx,2), %ebx
movl%edx, %ecx
jneL7
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9920] [Optimizer] Use mul/imul for integer division by constant
http://d.puremagic.com/issues/show_bug.cgi?id=9920 --- Comment #4 from Dmitry Olshansky 2013-04-11 12:28:08 PDT --- *** Issue 5607 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5607] Slow small integer division
http://d.puremagic.com/issues/show_bug.cgi?id=5607 Dmitry Olshansky changed: What|Removed |Added Status|NEW |RESOLVED CC||dmitry.o...@gmail.com Resolution||DUPLICATE --- Comment #2 from Dmitry Olshansky 2013-04-11 12:28:08 PDT --- *** This issue has been marked as a duplicate of issue 9920 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9920] [Optimizer] Use mul/imul for integer division by constant
http://d.puremagic.com/issues/show_bug.cgi?id=9920 --- Comment #3 from bearophile_h...@eml.cc 2013-04-11 11:33:55 PDT --- (In reply to comment #2) > any division by constant can be optimized. I didn't know this. > I'd say this one supersedes 5607, so how about merge your example here and > close 5607 ? (the 2 have to be merged anyway since the root cause is the same) If you think this supersedes 5607, then copy what you think should be copied, and close it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9920] [Optimizer] Use mul/imul for integer division by constant
http://d.puremagic.com/issues/show_bug.cgi?id=9920 --- Comment #2 from Dmitry Olshansky 2013-04-11 11:16:38 PDT --- (In reply to comment #1) > Dupe of 5607 ? 5607 is a special case of this enhancement. This one is generalization since any division by constant can be optimized. Using small divisors only allows some more specialized varations of this optimization (less accurate but enough for numbers in question). > > (Even if it's a dupe you have good code in attach) I'd say this one supersedes 5607, so how about merge your example here and close 5607 ? (the 2 have to be merged anyway since the root cause is the same) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9922] New: Improve symbol emitting for templates for better separate compilation support
http://d.puremagic.com/issues/show_bug.cgi?id=9922 Summary: Improve symbol emitting for templates for better separate compilation support Product: D Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: m.stras...@gmail.com --- Comment #0 from Dicebot 2013-04-11 11:09:58 PDT --- Currently all of them are generated to object file associated with module supplied to the command line. For separate compilation scenario that means that ALL template symbols from ALL imported modules are emitted into compiled single module. Most time it is just extra job for linker, but sometimes this results in nasty bugs when resulting symbols are not weak ones. Desired behavior: dmd will tries to find root module where template instantiation chain has started via call from non-templated scope. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9920] [Optimizer] Use mul/imul for integer division by constant
http://d.puremagic.com/issues/show_bug.cgi?id=9920 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2013-04-11 11:00:21 PDT --- Dupe of 5607 ? (Even if it's a dupe you have good code in attach) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9901] string return from inner template function error
http://d.puremagic.com/issues/show_bug.cgi?id=9901 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9901] string return from inner template function error
http://d.puremagic.com/issues/show_bug.cgi?id=9901 --- Comment #2 from github-bugzi...@puremagic.com 2013-04-11 10:44:15 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/ac4f2f4e42dc8404ae6a177944ea5183d2ba4a9c fix Issue 9901 - string return from inner template function error https://github.com/D-Programming-Language/dmd/commit/9432dd51cedc93cad54214974f810155e7648bea Merge pull request #1865 from 9rnsr/fix9901 Issue 9901 - string return from inner template function error -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6531] assertion failure in std.range.iota
http://d.puremagic.com/issues/show_bug.cgi?id=6531 safety0ff.b...@gmail.com changed: What|Removed |Added CC||safety0ff.b...@gmail.com --- Comment #9 from safety0ff.b...@gmail.com 2013-04-11 09:34:33 PDT --- Indeed, casting does not seem sufficient to force correct rounding of intermediate results. Seems like the solution is to either assign and force rounding, or use approxEqual with appropriate constants for the error terms. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9921] New: Enum variables of type void should be illegal
http://d.puremagic.com/issues/show_bug.cgi?id=9921
Summary: Enum variables of type void should be illegal
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2013-04-11 09:23:43 PDT ---
This compiles, but makes no sense.
enum X : void;
enum Z : void { Y };
(I already have a patch for this).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9920] New: [Optimizer] Use mul/imul for integer division by constant
http://d.puremagic.com/issues/show_bug.cgi?id=9920 Summary: [Optimizer] Use mul/imul for integer division by constant Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: dmitry.o...@gmail.com --- Comment #0 from Dmitry Olshansky 2013-04-11 08:44:06 PDT --- Created an attachment (id=1208) fast divison by constant for uint values It's a common knowledge and is totally expected for any modern compiler to re-write divisions by constant to double word width _multiplication_ by a specific constant followed by shift. DMD still DOESN'T DO it. Attached is an example of this optimization done via meta-programming in D along with test and a benchmark. On average (on my PC) the mul version is around 3 times faster then compiler-generated div. On LDC and GDC results are that compiler-generate version is a bit faster. Compiler can easily do a better job especially with 64bit values (as 2x64 accumulator is completely unaccessible for the programmer). For full description of one such technique see Agner Fog's manuals on assembly optimizations: http://www.agner.org/optimize/optimizing_assembly.pdf See the chapter 16. "Problematic instructions", section on DIV/IDIV is 16.9. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6531] assertion failure in std.range.iota
http://d.puremagic.com/issues/show_bug.cgi?id=6531 --- Comment #8 from drug007 2013-04-11 08:21:21 PDT --- (In reply to comment #7) > (In reply to comment #6) > > Martin Nowak's fix is the better (simpler and more clear) but I just don't > > like > > cast. > > I've tried his fix and it didn't work for me. Try mine. It works for me (with your example). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6531] assertion failure in std.range.iota
http://d.puremagic.com/issues/show_bug.cgi?id=6531 --- Comment #7 from Andrej Mitrovic 2013-04-11 08:13:26 PDT --- (In reply to comment #6) > Martin Nowak's fix is the better (simpler and more clear) but I just don't > like > cast. I've tried his fix and it didn't work for me. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6531] assertion failure in std.range.iota
http://d.puremagic.com/issues/show_bug.cgi?id=6531
drug007 changed:
What|Removed |Added
CC||drug2...@bk.ru
--- Comment #6 from drug007 2013-04-11 07:13:10 PDT ---
I propose the following:
auto pastEnd = start + count * step;
if (step > 0)
{
if (pastEnd < end) {
++count;
pastEnd = start + count * step;
}
assert(pastEnd >= end);
}
else
{
if (pastEnd > end) {
++count;
pastEnd = start + count * step;
}
assert(pastEnd <= end);
}
Martin Nowak's fix is the better (simpler and more clear) but I just don't like
cast.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9919] Regression (2.062): Symbol lookup fails with public import and mixin
http://d.puremagic.com/issues/show_bug.cgi?id=9919 Andrej Mitrovic changed: What|Removed |Added Keywords||rejects-valid --- Comment #2 from Andrej Mitrovic 2013-04-11 06:24:44 PDT --- Test-case is in the attachment. It works in 2.061, fails in 2.062 with: foo\bar\doo\b.d(5): Error: no property 'Action' for type 'foo.b.MouseEvent' foo\bar\doo\b.d(5): Error: MouseEvent.Action is used as a type -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9919] Regression (2.062): Symbol lookup fails with public import and mixin
http://d.puremagic.com/issues/show_bug.cgi?id=9919 --- Comment #1 from Andrej Mitrovic 2013-04-11 06:24:18 PDT --- Created an attachment (id=1207) test-case for Issue 9919 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9919] New: Regression (2.062): Symbol lookup fails with public import and mixin
http://d.puremagic.com/issues/show_bug.cgi?id=9919 Summary: Regression (2.062): Symbol lookup fails with public import and mixin Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: andrej.mitrov...@gmail.com --- Comment #0 from Andrej Mitrovic 2013-04-11 06:22:38 PDT --- Attachment will be added now. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 Andrei Alexandrescu changed: What|Removed |Added Status|NEW |RESOLVED CC||and...@erdani.com Resolution||FIXED --- Comment #20 from Andrei Alexandrescu 2013-04-11 06:12:47 PDT --- Thanks, Kenji! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 --- Comment #19 from bearophile_h...@eml.cc 2013-04-11 05:26:29 PDT --- The patch seems to work. With it I have removed five optimizations from my code. Very good. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9918] New: Strang error: void initializers for pointers not allowed in safe functions
http://d.puremagic.com/issues/show_bug.cgi?id=9918
Summary: Strang error: void initializers for pointers not
allowed in safe functions
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: andrej.mitrov...@gmail.com
--- Comment #0 from Andrej Mitrovic 2013-04-11
04:30:46 PDT ---
import std.path;
string joinPath(C)(const(C[])[] paths...) @safe pure
{
return buildNormalizedPath(buildPath(paths));
}
void main()
{
joinPath("foo", "bar");
}
Using 2.063 git-head:
test.d(7): Error: variable test.joinPath!(char).joinPath.__arrayArg2219 void
initializers for pointers not allowed in safe functions
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9539] Wrong implicit conversion of array to pointer
http://d.puremagic.com/issues/show_bug.cgi?id=9539 Kenji Hara changed: What|Removed |Added CC||phyph...@gmail.com --- Comment #7 from Kenji Hara 2013-04-11 01:54:36 PDT --- *** Issue 9916 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9916] int*[] implicitly converts to int*
http://d.puremagic.com/issues/show_bug.cgi?id=9916 Kenji Hara changed: What|Removed |Added Keywords||rejects-valid Component|Phobos |DMD Resolution|INVALID |DUPLICATE --- Comment #3 from Kenji Hara 2013-04-11 01:54:35 PDT --- (In reply to comment #2) > Yes, but the problem is it is compiling without error on 2.062 and that breaks > stuff Oh... I completely had mistaken. Sorry confusion by my wrong comment. Yes, this is actually a regression. It had occurred from 2.061, and still exists in 2.062. Fortunately, this regression had been found in the 2.063 devel, and already fixed in bug 9539. You would get the fix in 2.063 release. Thanks! *** This issue has been marked as a duplicate of issue 9539 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2356] array literal as non static initializer generates horribly inefficient code.
http://d.puremagic.com/issues/show_bug.cgi?id=2356 --- Comment #18 from github-bugzi...@puremagic.com 2013-04-11 01:36:48 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/8cd5f790a78e7514e46618d0325e92cbd6e00e48 fix Issue 2356 - array literal as non static initializer generates horribly inefficient code. https://github.com/D-Programming-Language/dmd/commit/d4b20baee7a1c9ee8a9271724feb5d1031e773d4 Merge pull request #1883 from 9rnsr/fix2356 Issue 2356 - array literal as non static initializer generates horribly inefficient code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3703] static array assignment
http://d.puremagic.com/issues/show_bug.cgi?id=3703 --- Comment #3 from github-bugzi...@puremagic.com 2013-04-11 01:36:43 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f703c5c6551affddd9213f759657a2b3e391b935 More fix for issue 3703 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9916] int*[] implicitly converts to int*
http://d.puremagic.com/issues/show_bug.cgi?id=9916 --- Comment #2 from phyph...@gmail.com 2013-04-11 01:32:09 PDT --- Yes, but the problem is it is compiling without error on 2.062 and that breaks stuff -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 9571] link error due to using unique ids in anonymous funcliteral
http://d.puremagic.com/issues/show_bug.cgi?id=9571 Dicebot changed: What|Removed |Added Keywords|pull| --- Comment #9 from Dicebot 2013-04-11 00:32:09 PDT --- Thanks for tracking down the root cause for this specific issue. I'll move my pull request to its own issue then. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
