[Issue 10818] Allow parameterized enum declaration
http://d.puremagic.com/issues/show_bug.cgi?id=10818 --- Comment #3 from Kenji Hara k.hara...@gmail.com 2013-08-16 22:57:47 PDT --- (In reply to comment #2) Are there any existing use cases that this would improve? I don't have actual use case. I'm proposing this enhancement just for increasing language consistency. --- Now I'm opening a compiler PR to extend DIP42 feature. https://github.com/D-Programming-Language/dmd/pull/2467 This is necessary to support `enum bool x(T) = initializer` syntax, and looks to me it is very similar to N3651 in C++14. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2013/n3651.pdf After #2467 is accepted, we would could make most of declarations parameterize - aggregates, functions, and variable declarations. And, at that time enum declaration would be remained just one declaration which cannot be parameterized. That would be inconsistent. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821 --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-17 01:59:09 PDT --- (In reply to comment #2) Oh actually, nevermind, the delegate removed itself from the hash. Ahhh, I see what's going on. You're modifying the AA while iterating over it. That's very bad, because byKey is implemented using a pointer to the current Slot. But once the delegate removes itself from the table, this pointer is invalidated. That's the bug in your code. :) Oh damn, I can't believe I've run into this hash issue again. And it's very hard to spot too. I hope we can make new hashes which are not unstable like this. Hows your new hashes branch going? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10831] using typeid in CTFE in imported file adds link dependency when generating debug info
http://d.puremagic.com/issues/show_bug.cgi?id=10831 --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2013-08-17 02:15:43 PDT --- Actually this fails on Win64 even without debug info: dmd -m64 test.d test.obj : error LNK2001: unresolved external symbol _D3imp1S6__initZ test.exe : fatal error LNK1120: 1 unresolved externals I guess it also fails on other platforms. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10833] DMD puts mixin's source code in the binary
http://d.puremagic.com/issues/show_bug.cgi?id=10833 --- Comment #2 from Temtaime temta...@gmail.com 2013-08-17 04:21:59 PDT --- I think there is no need to have any switches. If D debugger requires mixin's source - then source in binary should to be only when -g flag specified. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7260] g on default in std.regex
http://d.puremagic.com/issues/show_bug.cgi?id=7260 --- Comment #10 from Dmitry Olshansky dmitry.o...@gmail.com 2013-08-17 05:33:49 PDT --- The problem now should is addressed by this pull https://github.com/D-Programming-Language/phobos/pull/1470 There is matchAll/matchFirst calls now that are the prefered way to go about matching. Currently they simply override global flag if present. Returning to the original example: foreach (c; text.matchAll(1|2|3|4)) //this spins over captures of each match write(c, ); writeln(); foreach (c; text.matchFirst(1|2|3|4)) //this spins submatches of 1st match write(c, ); writeln(); To me there is little else to do aside from slooowly deprecating old flag-based match/replace interface. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10789] Struct destructor erroneously called
http://d.puremagic.com/issues/show_bug.cgi?id=10789 --- Comment #3 from S�nke Ludwig slud...@outerproduct.org 2013-08-17 07:31:21 PDT --- I digged a little in the DMD sources and found a commit by Kenji Hara that at least affects this example and has a commented out code block that looks a little suspicious : https://github.com/D-Programming-Language/dmd/commit/b4bc25d72e601436f3999abc5c9c31e464385052#L4R1241 Changing #if 0//DMDV2 back to #if DMDV2 inserts a proper postblit call, but then the returned t has its initialized field set to false. This does not happen with the #if 0 AFAICS. Unfortunately I know far to less about the mechanics at work there to make an informed attempt to fix this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10836] New: 'errors compiling the function' for optimized builds
http://d.puremagic.com/issues/show_bug.cgi?id=10836
Summary: 'errors compiling the function' for optimized builds
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2013-08-17 07:48:03 PDT ---
This could be a regression.
import std.stdio, std.array;
void main() {}
Compiling it with dmd 2.064alpha with:
dmd -O -release -inline -noboundscheck
It gives me:
...\dmd2\windows\bin\..\..\src\phobos\std\array.d: Error: function
std.array.Appender!(const(wchar)[]).Appender.Data.__xopEquals errors compiling
the function
While this program:
import std.array;
void main() {}
Gives me:
...\dmd2\windows\bin\..\..\src\phobos\std\uni.d(3547): Error: function
std.uni.TrieBuilder!(ubyte, dchar, 1114112, sliceBits!(13u, 21u),
sliceBits!(6u, 13u), sliceBits!(0u, 6u)).TrieBuilder.putAt errors compiling the
function
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10837] Extern as in-place linkage modifier
http://d.puremagic.com/issues/show_bug.cgi?id=10837 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||andrej.mitrov...@gmail.com Resolution||DUPLICATE --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-17 07:54:52 PDT --- *** This issue has been marked as a duplicate of issue 6754 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10837] New: Extern as in-place linkage modifier
http://d.puremagic.com/issues/show_bug.cgi?id=10837 Summary: Extern as in-place linkage modifier Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: weltenst...@gmail.com --- Comment #0 from Robert Luger weltenst...@gmail.com 2013-08-17 07:52:51 PDT --- It's not possible to directly take an extern(C) function pointer as argument: void receiveFunc(extern(C) void function() f); // error extern(C) alias void function() Func; void receiveFunc(Func f); // works In my particular case it is problematic when I use std.traits.fullyQualifiedName (for later use in a mixin) on a function type which takes a C function, because it returns a string similar to the first example. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6754] extern() in a function signature
http://d.puremagic.com/issues/show_bug.cgi?id=6754 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||weltenst...@gmail.com --- Comment #3 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-17 07:54:52 PDT --- *** Issue 10837 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 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821 --- Comment #4 from hst...@quickfur.ath.cx 2013-08-17 09:20:44 PDT --- I don't know if it's possible to make hash iteration stable across deletes. This isn't specific to hashes either; any data structure involving pointers will have this problem. If you have an iterator pointing to bucket B1, and then you delete B1 from inside the delegate and then try to advance the iterator, you will run into this problem. Even if you use an array to store your func ptrs, say, and keep an array index to track where you are. If you then delete the current element from inside the delegate and move the array elements up to fill in the gap, the loop wouldn't know about it, and would increment the index, skipping over what was supposed to be the next element. So your iteration breaks (even though in this case you won't get invalid pointers). It may be possible to hack around this particular instance of the problem, say by checking if the entry at the current index has changed, but it doesn't help in the general case, say if your delegate removes multiple entries from the array. Either way, your iteration will be screwed up. Basically, it's impossible to have straightforward iteration when you're modifying the container in the middle of things. Even your approach of using .key to get an array of keys is not reliable -- imagine if the delegate deletes some of the subsequent keys that you're about to visit. Then you'll get RangeErrors because the keys in the array no longer exist in the AA. I've had to deal with code that has to iterate over an array (or hash) of callbacks before (this was in C++ not D, but the same issues apply). I found that the only way to keep things consistent without strange side-effects was to keep a list of to-be-deleted entries separately, and the delegate would never modify the array of callbacks directly, but would append itself to the to-be-deleted list if it wants to remove itself. Then during the iteration, anything that is found in the to-be-deleted list is skipped, and after the iteration is finished, then loop through the to-be-deleted list and actually delete the entries. This kind of issue gets worse if the delegates have the possibility of triggering the destruction of the entire container. This is not applicable to your code, but I had to deal with this when writing a protocol stack with callback handlers -- the stack itself doesn't handle things like logout, it's all handled by callbacks, which makes it very tricky when one of the callbacks may be the logout handler, which will cleanup by destructing the entire protocol stack. Upon returning to the protocol stack code that called the callback in the first place, all references to the stack instance are now invalid, so basically callbacks must be called after everything else has been processed, otherwise it will segfault if the callback happens to be the logout handler. This code is so tricky that even years after I wrote it I still have to go back and fix subtle bugs in it every so often. tl;dr: modifying a container while iterating over it is tricky business, and is best avoided if you can. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10789] Struct destructor erroneously called
http://d.puremagic.com/issues/show_bug.cgi?id=10789 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added Severity|normal |regression --- Comment #4 from Maxim Fomin ma...@maxim-fomin.ru 2013-08-17 09:26:45 PDT --- (In reply to comment #3) I digged a little in the DMD sources and found a commit by Kenji Hara that at least affects this example and has a commented out code block that looks a little suspicious : https://github.com/D-Programming-Language/dmd/commit/b4bc25d72e601436f3999abc5c9c31e464385052#L4R1241 Changing #if 0//DMDV2 back to #if DMDV2 inserts a proper postblit call, but then the returned t has its initialized field set to false. This does not happen with the #if 0 AFAICS. Unfortunately I know far to less about the mechanics at work there to make an informed attempt to fix this. Sounds like a regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10776] std.json parseJSON has a bug.
http://d.puremagic.com/issues/show_bug.cgi?id=10776 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx 2013-08-17 09:47:56 PDT --- This violates RFC 4627 (http://www.ietf.org/rfc/rfc4627.txt), so it's definitely a bug in std.json. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7432] DMD allows variables to be declared as pure
http://d.puremagic.com/issues/show_bug.cgi?id=7432 Maxim Fomin ma...@maxim-fomin.ru changed: What|Removed |Added CC||ma...@maxim-fomin.ru --- Comment #6 from Maxim Fomin ma...@maxim-fomin.ru 2013-08-17 10:44:23 PDT --- This is a feature of D - in general case any attribute is legal (except those for which there are arbitrary checks and rejections) and auto can be replaced by other attributes to launch type inference. Since pure is harmless here I think this is resolved-wontfix. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821
--- Comment #5 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-17
11:00:42 PDT ---
(In reply to comment #4)
I found
that the only way to keep things consistent without strange side-effects was
to
keep a list of to-be-deleted entries separately, and the delegate would never
modify the array of callbacks directly, but would append itself to the
to-be-deleted list if it wants to remove itself.
Hmm yeah, it gets complicated real fast. Thanks for the insight.
So here's a quick safer workaround implementation:
-
struct Signal
{
void connect(void delegate(int) func)
{
if (emitting)
{
funcsToAdd[func] = 1;
}
else
{
stderr.writefln(Func connect: %s, *cast(void**)func);
funcs[func] = 1;
}
}
void disconnect(void delegate(int) func)
{
if (emitting)
{
funcsToDelete[func] = 1;
}
else
{
stderr.writefln(Func disconnect: %s, *cast(void**)func);
funcs.remove(func);
}
}
void emit(int i)
{
emitting = true;
scope(exit) emitting = false;
foreach (func; funcs.byKey)
{
stderr.writefln(Calling: %s, *cast(void**)func);
func(i);
}
foreach (func; funcsToDelete.byKey())
funcs.remove(func);
funcsToDelete = null;
foreach (func; funcsToAdd.byKey())
funcs[func] = 1;
funcsToAdd = null;
}
int[void delegate(int)] funcs;
int[void delegate(int)] funcsToAdd;
int[void delegate(int)] funcsToDelete;
bool emitting;
}
void main()
{
Signal signal;
void delegate(int) handler;
handler =
(int i)
{
signal.disconnect(handler);
};
signal.connect(handler);
signal.emit(1);
signal.emit(2);
signal.emit(3);
signal.emit(4);
}
-
Of course this still isn't perfect, there's no telling what a signal handler
really wants to do, whether it actually wants to add/remove some other handler
immediately or only schedule add/removal for later.
I guess the bottom line is this stuff is more complicated than I thought. I
wonder if that new signals implementation recently announced handles this sort
of stuff.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10838] New: Null pointer dereference in gc.gcx.Gcx.isMarked
http://d.puremagic.com/issues/show_bug.cgi?id=10838
Summary: Null pointer dereference in gc.gcx.Gcx.isMarked
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: peter.alexander...@gmail.com
--- Comment #0 from Peter Alexander peter.alexander...@gmail.com 2013-08-17
11:40:46 PDT ---
Running with with the attached file as stdin (/usr/share/dict/words on OSX
10.8.4) results in a seg fault.
import std.algorithm, std.range, std.array, std.stdio, std.string;
void main()
{
auto ws = stdin.byLine.map!(a = a.dup.toLower).array;
ws.zip(ws.map!(a = a.dup.sort)).
array.
sort!((a, b) = a[1] b[1]).
group!((a, b) = a[1] == b[1]).
array;
}
% dmd words.d
% gdb words
...
(gdb) run words dict
...
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0004
0x000100025e5d in D2gc3gcx3Gcx8isMarkedMFPvZE2gc3gcx8IsMarked ()
...
(gdb) bt
#0 0x000100025e5d in D2gc3gcx3Gcx8isMarkedMFPvZE2gc3gcx8IsMarked ()
#1 0x00010001ea5e in thread_processGCMarks ()
#2 0x000100025803 in D2gc3gcx3Gcx11fullcollectMFZm ()
#3 0x000100024b2e in D2gc3gcx3Gcx8bigAllocMFmPPS2gc3gcx4PoolPmZPv ()
#4 0x0001000223ac in D2gc3gcx2GC12mallocNoSyncMFmkPmZPv ()
#5 0x0001000221da in D2gc3gcx2GC6mallocMFmkPmZPv ()
#6 0x000100021822 in gc_qalloc ()
#7 0x00010001c5a4 in D4core6memory2GC6qallocFNaNbmkZS4core6memory8BlkInfo_
()
#8 0x00010001245f in
D3std5array88__T8AppenderTAS3std8typecons51__T5TupleTS3std8typecons16__T5TupleTAaTAaZ5TupleTkZ5TupleZ8Appender13ensureAddableMFmZv
()
#9 0x00010001275c in
D3std5array88__T8AppenderTAS3std8typecons51__T5TupleTS3std8typecons16__T5TupleTAaTAaZ5TupleTkZ5TupleZ8Appender82__T3putTS3std8typecons51__T5TupleTS3std8typecons16__T5TupleTAaTAaZ5TupleTkZ5TupleZ3putMFS3std8typecons51__T5TupleTS3std8typecons16__T5TupleTAaTAaZ5TupleTkZ5TupleZv
()
#10 0x000100011fac in
D3std5array149__T5arrayTSmain124__T5GroupS16main10__lambda10TSmain74__T11SortedRangeTAS3std8typecons16__T5TupleTAaTAaZ5TupleS14main9__lambda7Z11SortedRangeZ5GroupZ5arrayFSmain124__T5GroupS16main10__lambda10TSmain74__T11SortedRangeTAS3std8typecons16__T5TupleTAaTAaZ5TupleS14main9__lambda7Z11SortedRangeZ5GroupZAS3std8typecons51__T5TupleTS3std8typecons16__T5TupleTAaTAaZ5TupleTkZ5Tuple
()
#11 0x00011547 in _Dmain ()
#12 0x000100028cf9 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi7runMainMFZv ()
#13 0x000100028845 in
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFMDFZvZv ()
#14 0x000100028d45 in D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi6runAllMFZv ()
#15 0x000100028845 in
D2rt6dmain211_d_run_mainUiPPaPUAAaZiZi7tryExecMFMDFZvZv ()
#16 0x0001000287f9 in _d_run_main ()
#17 0x000100028628 in main ()
I'm running OSX 10.8.4 with DMD 2.063.
I've had no success so far trying to produce a smaller test case.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10838] Null pointer dereference in gc.gcx.Gcx.isMarked
http://d.puremagic.com/issues/show_bug.cgi?id=10838 --- Comment #1 from Peter Alexander peter.alexander...@gmail.com 2013-08-17 11:46:54 PDT --- Attaching failed as it's too big (2MB). You can find the file at http://poita.org/misc/dict -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821 --- Comment #6 from hst...@quickfur.ath.cx 2013-08-17 11:55:32 PDT --- (In reply to comment #5) [...] Of course this still isn't perfect, there's no telling what a signal handler really wants to do, whether it actually wants to add/remove some other handler immediately or only schedule add/removal for later. I think the only safe way is to always process adds/deletes immediately after iterating over the current handlers. Adds/removes for later can use a timer mechanism. Modifying a container while iterating over it is never a good idea. :) I guess the bottom line is this stuff is more complicated than I thought. I wonder if that new signals implementation recently announced handles this sort of stuff. Well, it should be audited for this, then. :) It should be fixed if it doesn't already handle this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7741] getHash inconsistent for const(char)[] vs. char[] and string
http://d.puremagic.com/issues/show_bug.cgi?id=7741 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #1 from hst...@quickfur.ath.cx 2013-08-17 12:06:02 PDT --- Fixed in git HEAD. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4380] Poor optimisation of x*x, where x is real
http://d.puremagic.com/issues/show_bug.cgi?id=4380 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx 2013-08-17 12:16:37 PDT --- This is still happening on git HEAD. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821 --- Comment #7 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-17 12:30:29 PDT --- (In reply to comment #6) Modifying a container while iterating over it is never a good idea. However some containers explicitly support this, like dcollections. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 7432] DMD allows variables to be declared as pure
http://d.puremagic.com/issues/show_bug.cgi?id=7432 Temtaime temta...@gmail.com changed: What|Removed |Added CC||temta...@gmail.com --- Comment #7 from Temtaime temta...@gmail.com 2013-08-17 12:36:11 PDT --- Pure variables it's strange. D is young lang so i think it's welcome to fix the bugs and change behavior even with breaking the code. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5842] hash table corruption
http://d.puremagic.com/issues/show_bug.cgi?id=5842 hst...@quickfur.ath.cx changed: What|Removed |Added Keywords||pull --- Comment #1 from hst...@quickfur.ath.cx 2013-08-17 13:05:46 PDT --- https://github.com/D-Programming-Language/druntime/pull/576 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10535] Add a function to druntime which returns an empty AA
http://d.puremagic.com/issues/show_bug.cgi?id=10535 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #2 from hst...@quickfur.ath.cx 2013-08-17 13:11:48 PDT --- (In reply to comment #1) Not to hijack this, but before we add that AA specific function, we should take into account that a LOT of other objects require this. Basically, every reference semantic object in Phobos: Containers, Appender, PRNGs... There might be a better generic solution to the empty initialization (eg: arg-less-constructor) problem. This does not preclude adding a function to aaA.d that returns an empty but non-null AA, since that will be needed anyway no matter what generic solution is provided to the end-user. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821 --- Comment #9 from hst...@quickfur.ath.cx 2013-08-17 13:19:20 PDT --- Besides, if you're iterating a RedBlackTree and then in the middle you delete all keys, I bet that your iteration will break in a rather ugly way. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821 --- Comment #8 from hst...@quickfur.ath.cx 2013-08-17 13:17:55 PDT --- It does not eliminate the bad behaviour though. Suppose you're iterating over a RedBlackTree, and then add and delete some keys. Depending on whether those keys are greater or less than the current key, they will be included / excluded from the current iteration. So whether the key will be found in the current iteration depends on the relative values of the current key and the key being added/deleted, and there's no way to change this apart from scheduling adds/deletes after the iteration is over. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8746] rehash AA property doesn't work with constant Tuple
http://d.puremagic.com/issues/show_bug.cgi?id=8746 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx 2013-08-17 13:29:01 PDT --- This no longer seems to happen on git HEAD. Has it been fixed? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10839] New: Lambda function formatting in error messages
http://d.puremagic.com/issues/show_bug.cgi?id=10839
Summary: Lambda function formatting in error messages
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 2013-08-17 14:16:42 PDT ---
In the following code if I define const foo, the code compiles:
import std.algorithm: map;
void main() {
//const foo = (int x) = x; // OK
enum foo = (int x) = x; // error
[1].map!foo;
}
If I use enum foo I receive the error messages, dmd 2.064alpha:
...\dmd2\src\phobos\std\algorithm.d(410): Error: function
std.algorithm.MapResult!(int(int x)
{
return x;
}
, int[]).MapResult.back cannot access frame of function D main
...\dmd2\src\phobos\std\algorithm.d(444): Error: function
std.algorithm.MapResult!(int(int x)
{
return x;
}
, int[]).MapResult.front cannot access frame of function D main
...\dmd2\src\phobos\std\algorithm.d(456): Error: function
std.algorithm.MapResult!(int(int x)
{
return x;
}
, int[]).MapResult.opIndex cannot access frame of function D main
...\dmd2\src\phobos\std\algorithm.d(396): Error: template instance
std.algorithm.MapResult!(int(int x)
{
return x;
}
, int[]) error instantiating
bug.d(5):instantiated from here: map!(int[])
bug.d(5): Error: template instance std.algorithm.map!(int(int x)
{
return x;
}
).map!(int[]) error instantiating
I think a better formatting for those error messages could be:
...\dmd2\src\phobos\std\algorithm.d(410): Error: function
std.algorithm.MapResult!(int(int x) { return x; }, int[]).MapResult.back cannot
access frame of function D main
...\dmd2\src\phobos\std\algorithm.d(444): Error: function
std.algorithm.MapResult!(int(int x) { return x; }, int[]).MapResult.front
cannot access frame of function D main
...\dmd2\src\phobos\std\algorithm.d(456): Error: function
std.algorithm.MapResult!(int(int x) { return x; }, int[]).MapResult.opIndex
cannot access frame of function D main
...\dmd2\src\phobos\std\algorithm.d(396): Error: template instance
std.algorithm.MapResult!(int(int x) { return x; }, int[]) error instantiating
bug.d(5):instantiated from here: map!(int[])
bug.d(5): Error: template instance std.algorithm.map!(int(int x) { return x;
}).map!(int[]) error instantiating
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821 --- Comment #10 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-17 14:36:30 PDT --- (In reply to comment #8) It does not eliminate the bad behaviour though. Suppose you're iterating over a RedBlackTree, and then add and delete some keys. I was thinking of the purge method in various dcollection containers (purge doesn't seem to be in Phobos), it's explicitly used for removal during traversal. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10840] New: [CTFE] *this._data.arr is not yet implemented at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=10840
Summary: [CTFE] *this._data.arr is not yet implemented at
compile time
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dmitry.o...@gmail.com
--- Comment #0 from Dmitry Olshansky dmitry.o...@gmail.com 2013-08-17
14:54:39 PDT ---
Found while working on std.regex. std.array.Append will sometimes fail with
that message.
Simpified test case:
bool empty(int[] arr)
{
return arr.length == 0;
}
struct Appender
{
private struct Data
{
size_t capacity;
int[] arr;
}
private Data* _data;
@property int[] data() @trusted pure nothrow
{
return (_data ? _data.arr : null);
}
}
struct Stack
{
Appender stack;
@property bool empty(){ return stack.data.empty; }
}
bool foo()
{
Stack app;
return app.empty;
}
pragma(msg, foo());
Outputs (tested with git HEAD 2.064):
ctfe_fail.d(18): Error: *this._data.arr is not yet implemented at compile time
ctfe_fail.d(25):called from here: this.stack.data()
ctfe_fail.d(25):called from here: empty(this.stack.data())
ctfe_fail.d(32):called from here: app.empty()
ctfe_fail.d(36):called from here: foo()
ctfe_fail.d(36):while evaluating pragma(msg, foo())
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10821] .byKey erroneously returns a null key
http://d.puremagic.com/issues/show_bug.cgi?id=10821
--- Comment #11 from hst...@quickfur.ath.cx 2013-08-17 15:15:12 PDT ---
Sorry, I mistakenly thought you were talking about std.container. :-/
Anyway, looking over the dcollections code, I'm pretty impressed to realize
that foreach can take function pointers?! That's something I've never knew
before!
In any case, purge is basically a restricted form of container modification
while iterating -- it iterates over the elements and lets you decide whether or
not to remove each one. This is a more controlled form of container
modification during iteration, and is made safe by (1) (implicitly) caching the
reference to the next element and not advancing the iterator if the element
*was* elected to be removed, and (2) only allowing the current element to be
removed, not any arbitrary element. If you relax (2), say your foreach body
directly references the container and deletes random elements, then all hell
breaks loose. If you enforce (2), then you can use (1) as implementation
strategy to allow deletion during iteration.
So one possibility in the case of your signal/slot code, is to have the
delegate return a bool/flag to indicate whether to remove itself from the
table. That way, you can avoid keeping lists of what to remove after the
iteration. It won't be as nice as a foreach loop, though, since you have to
manually control where your iterator is:
auto r = aa.byKey;
while (!r.empty) {
auto key = r.front;
auto dg = aa[key];
bool deleteDg = dg(args) == Flag.deleteMe;
r.popFront(); // important: this must come before aa.remove(key)
if (deleteDg == Flag.deleteMe) {
aa.remove(key);
}
}
By advancing the range before the aa.remove(key) call and only allowing the
current element to be deleted, you avoid running into invalid pointers.
This doesn't address the problem with dg inserting new things into aa, though,
since the newly inserted entry may or may not get iterated over by the loop
depending on where its hash value falls relative to the current position of the
byKey range. So there's still some unpredictability there.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10782] dmd segfault with string mixin, CTFE, class, non-literal initializer
http://d.puremagic.com/issues/show_bug.cgi?id=10782 Walter Bright bugzi...@digitalmars.com 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 10782] dmd segfault with string mixin, CTFE, class, non-literal initializer
http://d.puremagic.com/issues/show_bug.cgi?id=10782 --- Comment #3 from github-bugzi...@puremagic.com 2013-08-17 18:02:40 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/55447560bcf1a1f2b97083819244f65709aa5f2f fix Issue 10782 - dmd segfault with string mixin, CTFE, class, non-literal initializer https://github.com/D-Programming-Language/dmd/commit/13a0da419abf24549fa8f1caf0dceec373c477cb Merge pull request #2478 from 9rnsr/fix10782 Issue 10782 - dmd segfault with string mixin, CTFE, class, non-literal initializer -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10841] New: std.conv.parse failed when parsing a slice string
http://d.puremagic.com/issues/show_bug.cgi?id=10841 Summary: std.conv.parse failed when parsing a slice string Product: D Version: D2 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bitwo...@qq.com --- Comment #0 from Heromyth bitwo...@qq.com 2013-08-17 18:14:55 PDT --- The test code is here: //= string s1 = 11AB; auto r = parse!int(s1[0..2], 16); //= It worked with DMD 2.062, but failed with DMD 2.063.2. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10842] New: auto return function not executed depending on how it's called
http://d.puremagic.com/issues/show_bug.cgi?id=10842
Summary: auto return function not executed depending on how
it's called
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: critical
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thelastmamm...@gmail.com
--- Comment #0 from thelastmamm...@gmail.com 2013-08-17 18:28:51 PDT ---
dmd -version=A -run main.d: prints nothing
dmd -version=B -run main.d: prints ok
auto fail(){
import std.stdio;
writeln(ok);
/+
//would be same with this:
assert(0);
//or this:
import std.exception; throw new Exception(bad);
+/
return null;
}
string foo(){
version(A){
auto temp=fail();
return temp;
}
else
return fail();
}
void main(){
foo();
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10842] auto return function not executed depending on how it's called
http://d.puremagic.com/issues/show_bug.cgi?id=10842
Andrej Mitrovic andrej.mitrov...@gmail.com changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-17
18:40:12 PDT ---
Reduced:
-
auto ret1()
{
assert(0); // should throw, doesn't
return null;
}
string test1()
{
return ret1();
}
void main()
{
test1();
}
-
If you change the return to an explicit expression, e.g. `return `, then the
assert is triggered.
Also perhaps noteworthy is that in older releases the reduced code used to fail
to compile, e.g. in 2.057:
Error: e2ir: cannot cast ret1() of type typeof(null) to type string
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10841] std.conv.parse failed when parsing a slice string
http://d.puremagic.com/issues/show_bug.cgi?id=10841 Jonathan M Davis jmdavisp...@gmx.com changed: What|Removed |Added Status|NEW |RESOLVED CC||jmdavisp...@gmx.com Resolution||INVALID --- Comment #1 from Jonathan M Davis jmdavisp...@gmx.com 2013-08-17 18:42:41 PDT --- If it worked with 2.062, it was a bug. parse accepts its argument by ref (because it alters the argument by popping characters off of it as they're parsed), which means that the argument must be an lvalue, and a slice is not an lvalue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10841] std.conv.parse failed when parsing a slice string
http://d.puremagic.com/issues/show_bug.cgi?id=10841 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #2 from Andrej Mitrovic andrej.mitrov...@gmail.com 2013-08-17 18:51:09 PDT --- The rationale of the change is in the changelog: http://dlang.org/changelog.html#sliceref As a workaround you'll have to assign s1[0..2] to another variable and pass it to parse. A better alternative is to use to!() instead of parse!(): string s1 = 11AB; auto r = to!int(s1[0..2], 16); There /was/ some brief discussion about making parse work with slices as well, since it could be considered convenient (and would avoid code breakage), but there was no outcome for the 2.063 release. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4380] Poor optimisation of x*x, where x is real
http://d.puremagic.com/issues/show_bug.cgi?id=4380
yebblies yebbl...@gmail.com changed:
What|Removed |Added
CC||yebbl...@gmail.com
--- Comment #2 from yebblies yebbl...@gmail.com 2013-08-18 14:02:45 EST ---
In cg87, line 1661 (load87) it has this code:
if ((ty == TYldouble || ty == TYildouble)
op != -1 e-Eoper != OPd_ld)
goto Ldefault;
op is 0 here (OPvar), and ty == TYldouble, so all the normal var cse checking
is skipped.
Down at 1887, we have
#if 1 /* Do this instead of codelem() to avoid the freenode(e).
We also lose CSE capability */
if (e-Eoper == OPconst)
{
c = load87(e, 0, retregs, NULL, -1);
}
else
c = (*cdxxx[e-Eoper])(e,retregs);
#else
c = codelem(e,retregs,FALSE);
#endif
So it looks like this was intentional to avoid some kind of compiler internal
bug. Removing both conditions results in the correct code, but who knows what
else it breaks.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 10234] Class declaration grammar seems to be incorrect
http://d.puremagic.com/issues/show_bug.cgi?id=10234 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #2 from yebblies yebbl...@gmail.com 2013-08-18 14:08:46 EST --- dmd's parser is correct here. The ability to receive almost any type was added to satisfy bug 1353 and bug 8513 - any non-class types are rejected during semantic instead. This has the side effect of making error messages much better if anybody _did_ try to make a class inherit from 'int'. So this is purely a spec bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 10843] New: Combinatorial problem of struct alias this null
http://d.puremagic.com/issues/show_bug.cgi?id=10843
Summary: Combinatorial problem of struct alias this null
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO zan77...@nifty.com 2013-08-17 22:03:19 PDT ---
These tree samples don't work:
--
unittest
{
static struct HANDLE
{
void* h;
alias h this;
}
//HANDLE a = null; // NG
HANDLE a;
a = null; // OK
}
unittest
{
static struct HANDLE
{
void* h;
alias h this;
this(void* h) { this.h = h; }
}
HANDLE a = null; // OK
static void foo(HANDLE h){}
//foo(null); // NG
}
unittest
{
static struct HANDLE
{
void* h;
alias h this;
this(void* h) { this.h = h; }
}
static struct WSAEVENT
{
HANDLE h;
alias h this;
this(HANDLE h) { this.h = h; }
}
auto a = cast(HANDLE)null; // OK
//auto b = cast(WSAEVENT)null; // NG
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
