[Issue 4917] New: Symbol conflict error message refers to aliased symbol instead of the alias
http://d.puremagic.com/issues/show_bug.cgi?id=4917 Summary: Symbol conflict error message refers to aliased symbol instead of the alias Product: D Version: D1 Platform: Other OS/Version: Linux Status: NEW Keywords: diagnostic Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: nfx...@gmail.com --- Comment #0 from nfx...@gmail.com 2010-09-22 23:00:04 PDT --- $ cat aaa.d int x; alias x y; int y; $ dmd aaa.d aaa.d(1): Error: variable aaa.x conflicts with variable aaa.y at aaa.d(3) It should say: aaa.d(2): Error: variable aaa.y conflicts with variable aaa.y at aaa.d(3) dmd resolves the alias to the original symbol when producing the error message, although the alias caused the error (and not the original symbol). Additionally none of the line numbers point to the line causing the error. Think how confusing this could be in larger codebases. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4886] Template (alias) tuple parameters cannot take .length property in compiletime
http://d.puremagic.com/issues/show_bug.cgi?id=4886
--- Comment #2 from Shin Fujishiro 2010-09-22 22:04:28 PDT
---
Created an attachment (id=764)
Patch against dmd r680, fixes resolveHelper()
This patch fixes the reported issue and bug 2953 (D2). It passed dmd, druntime
and phobos tests.
The patch also fixes the following problems:
struct R
{
alias int T;
}
struct S
{
R r;
alias r this;
}
S.T x; // (10)
int[S.r.offsetof] y;// (11)
% dmd -o- -c test.d
test.d(10): Error: S.T is used as a type
test.d(11): Error: no property 'offsetof' for type 'R'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4916] New: struct VariantN does not overload ()
http://d.puremagic.com/issues/show_bug.cgi?id=4916
Summary: struct VariantN does not overload ()
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: ah0801...@yahoo.com
--- Comment #0 from Austin Hastings 2010-09-22 20:11:45
PDT ---
This code:
==
module scratch;
import std.variant;
unittest {
Variant v;
int foo() { return 1; }
v = &foo;
v();
}
Produces this error:
$ dmd -unittest -run bronze/util/scratch.d
bronze\util\scratch.d(12): Error: struct VariantN does not overload ()
===
IMO, this is a design flaw: Variants claim to support function and delegate
pointers, and it seems obvious that supporting them should support invoking
them. (In particular, since functions and delegates are different sizes,
Variants should be very useful in this role, except ...)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4465] ICE(symbol.c): immutable type inference with ^^2
http://d.puremagic.com/issues/show_bug.cgi?id=4465 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #4 from Walter Bright 2010-09-22 17:44:54 PDT --- http://www.dsource.org/projects/dmd/changeset/685 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4869] auto return + inheritance + modules = compiler crashes(toctype.c)
http://d.puremagic.com/issues/show_bug.cgi?id=4869 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #5 from Walter Bright 2010-09-22 16:18:38 PDT --- http://www.dsource.org/projects/dmd/changeset/684 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4717] std.bitmanip.BitArray changes
http://d.puremagic.com/issues/show_bug.cgi?id=4717
--- Comment #10 from Don 2010-09-22 13:10:44 PDT ---
(In reply to comment #9)
> See also:
> http://www.strchr.com/crc32_popcnt
> http://wm.ite.pl/articles/sse-popcount.html
Yes, I saw those.
I made a simple 256-entry table lookup implementation (below, not optimised for
size) which runs at 5 cycles for 4 bytes. It'd be painful to beat that for
general-purpose 32 bit code (because AMD 32bit processors don't support SSE2).
Cache misses will kill you, though, unless the array is quite long.
I include my code here anyway, for future reference.
For 64 bits, SWAR on SSE2 is a clear winner.
--
const(uint[256]) makepopcountlookup(){
uint [256] result;
for (int i = 0; i<= 0xFF; ++i)
{
result[i] = (i&1) + ((i&2)>>1) + ((i&4)>>2) + ((i&8)>>3) +
((i&16)>>4) + ((i&32)>>5) + ((i&64)>>6) + ((i&128)>>7);
}
return result;
}
__gshared uint[256] POPCOUNT_LOOKUP_TABLE = makepopcountlookup();
/*
A lookup table is normally a bad way to do popcount since it risks a cache
miss.
But 1K table is not so terrible, and we're dealing with a large source array.
The address of the lookup table is passed as a parameter to avoid PIC
problems.
*/
int popcountArray(uint[] src, uint *lookuptable = &POPCOUNT_LOOKUP_TABLE[0])
{
enum { LASTPARAM = 4*4 } // 3* pushes + return address.
// TIMING: Core2: 12uops, 5.0 cycles/uint
// It's entirely limited by the 5 loads.
asm {
naked;
push ESI;
push EDI;
push EBX;
mov EDI, EAX; // EDI = lookup table.
mov ECX, [ESP + LASTPARAM + 0*4]; // src.length;
mov ESI, [ESP + LASTPARAM + 1*4]; // src.ptr
xor EAX, EAX;
lea ESI, [ESI + 4*ECX]; // ESI = end of src
neg ECX; // count UP to zero.
mov EBX, [ESI + 4*ECX];
xor EDX, EDX;
add ECX, 1;
jz onlyone;
L1:
add EAX, [EDI + EDX * 4];
movzx EDX, BL;
add EAX, [EDI + EDX * 4];
movzx EDX, BH;
shr EBX, 16;
add EAX, [EDI + EDX * 4];
movzx EDX, BH;
add EAX, [EDI + EDX * 4];
movzx EDX, BL;
mov EBX, [ESI + 4*ECX];
add ECX, 1;
jnz L1;
onlyone:
add EAX, [EDI + EDX * 4];
movzx EDX, BL;
add EAX, [EDI + EDX * 4];
movzx EDX, BH;
shr EBX, 16;
add EAX, [EDI + EDX * 4];
movzx EDX, BH;
add EAX, [EDI + EDX * 4];
movzx EDX, BL;
add EAX, [EDI + EDX * 4];
pop EBX;
pop EDI;
pop ESI;
ret 2*4;
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2294] negative default values for int template arguments does not work
http://d.puremagic.com/issues/show_bug.cgi?id=2294 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WORKSFORME --- Comment #3 from Don 2010-09-22 12:37:55 PDT --- Without some evidence that this is still current, I'm marking this as closed. Reopen if still current, with information on which platform it is visible on. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2294] negative default values for int template arguments does not work
http://d.puremagic.com/issues/show_bug.cgi?id=2294 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #2 from Don 2010-09-22 12:35:59 PDT --- I can reproduce this on codepad. Codepad claims to be using DMD 1.026, but 1.026 definitely works on Windows. This was probably fixed a very long time ago. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4717] std.bitmanip.BitArray changes
http://d.puremagic.com/issues/show_bug.cgi?id=4717 --- Comment #9 from bearophile_h...@eml.cc 2010-09-22 12:24:24 PDT --- See also: http://www.strchr.com/crc32_popcnt http://wm.ite.pl/articles/sse-popcount.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2331] Enum hashes many times slower than normal hashes
http://d.puremagic.com/issues/show_bug.cgi?id=2331 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #7 from bearophile_h...@eml.cc 2010-09-22 11:40:48 PDT --- (In reply to comment #6) > Walter, don't you think your users are finally annoyed enough > so that you could look into fixing it? Be more gentle, please. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2331] Enum hashes many times slower than normal hashes
http://d.puremagic.com/issues/show_bug.cgi?id=2331 nfx...@gmail.com changed: What|Removed |Added CC||nfx...@gmail.com --- Comment #6 from nfx...@gmail.com 2010-09-22 10:51:38 PDT --- (In reply to comment #1) > What's happening is that the static this() constructor builds the hash table > once. The enum version builds it every time it is used, as the enum name is > replaced with its initializer. That's quite hilarious. There are now half a dozen of bugs related to dmd being stupid with static data construction. E.g. see bug 4397, bug 2526, bug 2356, bug 4881. They possibly are all caused by the same underlying issue. Walter, don't you think your users are finally annoyed enough so that you could look into fixing it? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2331] Enum hashes many times slower than normal hashes
http://d.puremagic.com/issues/show_bug.cgi?id=2331 Mitch Hayenga changed: What|Removed |Added CC||mitch.haye...@gmail.com --- Comment #5 from Mitch Hayenga 2010-09-22 10:22:20 PDT --- I recently hit this performance issue myself while trying to use a lookup table, rather than branching on logic for a function. It can be avoided by declaring the field as invariant, but I had originally used Enum as thats one of the ways suggested by TDPL for doing CTFE. pseudocode: bool[256] generate_lookup_table(); // function declaration // Performance = terrible here enum lookup_as_enum = generate_lookup_table(); // Performance = great here invariant lookup_as_enum = generate_lookup_table(); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4866] Static-to-dynamic converted manifest constant array gets non-converted type in static/constraint if
http://d.puremagic.com/issues/show_bug.cgi?id=4866 --- Comment #1 from Shin Fujishiro 2010-09-22 10:11:55 PDT --- Created an attachment (id=763) Patch against dmd r680, fixes VarDeclaration::semantic() The problem was that VarDeclaration::semantic() doesn't take it into account when the variable is a manifest constant or the initializer is non-scalar. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4915] auto return type escapes function purity
http://d.puremagic.com/issues/show_bug.cgi?id=4915
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #1 from Don 2010-09-22 08:18:15 PDT ---
Actually, the bug is something different:
pure auto f() { return 0; }
pure int g() { return f(); }
bug.d(3): Error: pure function 'g' cannot call impure function 'f'
The bug is that for 'auto' functions, 'pure' is ignored.
Bug 3359 is another aspect of the same thing. In fact I think there are about
five bugs which probably all have the same root cause.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2832] pure function too pure
http://d.puremagic.com/issues/show_bug.cgi?id=2832 --- Comment #8 from Tomash Brechko 2010-09-22 08:05:37 PDT --- Created separate issue http://d.puremagic.com/issues/show_bug.cgi?id=4915 for "int -> auto", as auto return type escapes pure completely. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4915] New: auto return type escapes function purity
http://d.puremagic.com/issues/show_bug.cgi?id=4915
Summary: auto return type escapes function purity
Product: D
Version: 2.039
Platform: x86_64
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: tomash.brec...@gmail.com
--- Comment #0 from Tomash Brechko 2010-09-22
08:03:34 PDT ---
dmd 2.039 doesn't produce error for pure function with auto return type that
violates purity:
int global;
pure auto f()
{
global = 1;
return 0;
}
compiles without errors.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2832] pure function too pure
http://d.puremagic.com/issues/show_bug.cgi?id=2832
Tomash Brechko changed:
What|Removed |Added
CC||tomash.brec...@gmail.com
--- Comment #7 from Tomash Brechko 2010-09-22
07:39:43 PDT ---
Note that (with dmd 2.049)
pure int f(int i)
{
return ++i;
}
doesn't compile, yet
pure auto f(int i)
{
return ++i;
}
does work (int return type is replaced with auto).
Also http://www.digitalmars.com/d/2.0/function.html section "Pure Functions"
gives an example of assignment to parameter,
i = y;// ok, reading immutable global state
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3602] ICE(tocsym.c) compiling a class, if its super class has preconditions
http://d.puremagic.com/issues/show_bug.cgi?id=3602 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #10 from Walter Bright 2010-09-22 06:24:00 PDT --- http://www.dsource.org/projects/dmd/changeset/683 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3516] Destructor not called on temporaries
http://d.puremagic.com/issues/show_bug.cgi?id=3516 --- Comment #9 from Don 2010-09-22 04:05:41 PDT --- *** Issue 4613 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 4613] temporary generated inside foreach is not correctly destructed
http://d.puremagic.com/issues/show_bug.cgi?id=4613 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Don 2010-09-22 04:05:41 PDT --- *** This issue has been marked as a duplicate of issue 3516 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4289] template struct opEquals problem
http://d.puremagic.com/issues/show_bug.cgi?id=4289 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #1 from Don 2010-09-22 03:40:56 PDT --- *** This issue has been marked as a duplicate of issue 3607 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3607] Regression(2.037) Problems with struct opEquals and const
http://d.puremagic.com/issues/show_bug.cgi?id=3607 Don changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from Don 2010-09-22 03:40:56 PDT --- *** Issue 4289 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 3607] Regression(2.037) Problems with struct opEquals and const
http://d.puremagic.com/issues/show_bug.cgi?id=3607 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au Summary|Problems with struct|Regression(2.037) Problems |opEquals and const |with struct opEquals and ||const Severity|normal |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4738] ICE using null array in static/constraint if
http://d.puremagic.com/issues/show_bug.cgi?id=4738 --- Comment #4 from Koroskin Denis <2kor...@gmail.com> 2010-09-22 03:07:47 PDT --- Original test case has been fixed so I'll create a new report. Sorry for the buzz. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4738] ICE using null array in static/constraint if
http://d.puremagic.com/issues/show_bug.cgi?id=4738 Koroskin Denis <2kor...@gmail.com> changed: What|Removed |Added CC||2kor...@gmail.com --- Comment #3 from Koroskin Denis <2kor...@gmail.com> 2010-09-22 03:05:52 PDT --- Got this issue today. Should I reopen the bug or submit a new ticket? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4914] New: Assertion failure: 'pr != PREC_zero' on line 817 in file 'expression.c'
http://d.puremagic.com/issues/show_bug.cgi?id=4914
Summary: Assertion failure: 'pr != PREC_zero' on line 817 in
file 'expression.c'
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: ah0801...@yahoo.com
--- Comment #0 from Austin Hastings 2010-09-22 02:12:33
PDT ---
This code generates the failure. I tried moving the method out of the class to
a function, but the problem went away - there may be an intermediate level of
complexity that I passed by.
class Foo {
int[string] builders;
bool remove() {
return builders.remove( "" );
}
}
I get:
Assertion failure: 'pr != PREC_zero' on line 817 in file 'expression.c'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
