[Issue 13564] [REG2.065] nested struct destructor trying to access members of a global class fail to compile
https://issues.dlang.org/show_bug.cgi?id=13564 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Hardware|x86_64 |All Summary|nested struct destructor|[REG2.065] nested struct |trying to access members of |destructor trying to access |a global class fail to |members of a global class |compile |fail to compile OS|Linux |All Severity|normal |regression --- Comment #1 from Kenji Hara k.hara...@gmail.com --- This is a dmd regression from 2.065. https://github.com/D-Programming-Language/dmd/pull/4040 --
[Issue 13349] [Mago] Wrong breakpoint locations in v0.3.39-beta2
https://issues.dlang.org/show_bug.cgi?id=13349 --- Comment #7 from Rainer Schuetze r.sagita...@gmx.de --- Please try https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.39-rc1, the issue should be gone now. --
[Issue 13556] inconsistent 'new' syntax for arrays
https://issues.dlang.org/show_bug.cgi?id=13556 --- Comment #4 from bearophile_h...@eml.cc --- (In reply to Kenji Hara from comment #3) Current ambituity syntax new int[2][1] should be deprecated, removed, and then we can reuse it for static array allocation. I suggest you to make you usual long table of all possible combinations, to show me what to allow and what to deprecate :-) If we manage to improve the array creation syntax it's going to be a significant improvement for D, because I use arrays all the time. --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate
https://issues.dlang.org/show_bug.cgi?id=8621 ent...@cantab.net changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE |--- --- Comment #4 from ent...@cantab.net --- Not a duplicate. The present bug talks about corrupt values coming out of thin air. I quote myself: The sort of corrupt values I see for z are for example 28835840 = 0x01B8 29949952 = 0x01C9 38535168 = 0x024C 36110336 = 0x0227 But it's always the same between one writeln and the other. This is not happening at all in the other bug. The other bug is more like the well-known C# foreach lambda problem, but on steroids. --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate, resulting in completely corrupt large values appearing
https://issues.dlang.org/show_bug.cgi?id=8621 ent...@cantab.net changed: What|Removed |Added Summary|Iteration variable in |Iteration variable in |foreach not closed upon |foreach not closed upon |properly in delegate|properly in delegate, ||resulting in completely ||corrupt large values ||appearing --
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043 ent...@cantab.net changed: What|Removed |Added CC||ent...@cantab.net Summary|Closure outer variables in |Closure outer variables in |nested blocks are not |nested blocks are not |allocated/instantiated |allocated/instantiated |correctly. |correctly: should have ||multiple instances but only ||have one. --- Comment #12 from ent...@cantab.net --- Expanded summaries a little on this bug and on 8621 to prevent further confusion - they are not duplicates. --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 --- Comment #34 from Steven Schveighoffer schvei...@yahoo.com --- (In reply to Ketmar Dark from comment #33) (In reply to Steven Schveighoffer from comment #30) bearophile or ketmar, can you test the new PR? for what reason? see #2 and #3, i was tried the variant without caching in remove(). This PR should have identical performance as your latest for the code in question, but not cause any slowdown for remove otherwise. But my box for some reason doesn't even exhibit the original problem with no patch. The speedup on my system is not measurable. So I need someone to test to make sure it's actually fixing the issue properly who does experience the problem. i'm telling again that remove() is NOT slowed down by any noticable time, and if you doing alot of removes which all happen to hit the first used bucket, and each such hit empties that bucket, and you used .byKey/.byValue before… this is very unusual scenario, and if you *know* that it goes like this, you can force rehashing. As has been discussed, this isn't an acceptable tradeoff. Forcing a rehash for this seems unintuitive, users will not get it. Besides, there is no reason to recalculate cache unless you need it. yet i'm not interested in defending the code: i integrated it in my local builds since i published the patch and it's ok for me. i don't really care if it will make to mainline in one form on another. Hm... people here have made a lot of effort to work with your patch given your objections to github. Normally I would suggest that unless you submit a PR, you will not get this code included. Your response confirms that should have been the correct action, and I'll remember that from now on. --
[Issue 13349] [Mago] Wrong breakpoint locations in v0.3.39-beta2
https://issues.dlang.org/show_bug.cgi?id=13349 --- Comment #8 from Denis Shelomovskij verylonglogin@gmail.com --- (In reply to Rainer Schuetze from comment #7) Please try https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.39-rc1, the issue should be gone now. As I wrote: Sometimes half of module lines background is filled when setting a single breakpoint (before and after the breakpoint) So the breakpoint line is still sometimes located before actual breakpoint. Sorry, it wasn't shown in the testcase. Will create a new one. --
[Issue 4890] GC.collect() deadlocks multithreaded program.
https://issues.dlang.org/show_bug.cgi?id=4890 --- Comment #31 from Sobirari Muhomori dfj1es...@sneakemail.com --- Hmm... stack trace in issue 11806 is quite different. --
[Issue 13349] [Mago] Wrong breakpoint locations in v0.3.39-beta2
https://issues.dlang.org/show_bug.cgi?id=13349 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Attachment #1440|0 |1 is obsolete|| --- Comment #9 from Denis Shelomovskij verylonglogin@gmail.com --- Created attachment 1443 -- https://issues.dlang.org/attachment.cgi?id=1443action=edit Testcase with incorrect breakpoint line --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate, resulting in completely corrupt large values appearing
https://issues.dlang.org/show_bug.cgi?id=8621 Gabor Mezo gabor.m...@outlook.com changed: What|Removed |Added CC||gabor.m...@outlook.com --- Comment #5 from Gabor Mezo gabor.m...@outlook.com --- I can confirm that this issue is NOT present on DMD 2.066.0 Windows. --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate, resulting in completely corrupt large values appearing
https://issues.dlang.org/show_bug.cgi?id=8621 --- Comment #6 from ent...@cantab.net --- Great - I haven't retested recently. Feel free to resolve :) --
[Issue 8848] Array literals and AA literals are rejected as template value parameters
https://issues.dlang.org/show_bug.cgi?id=8848 --- Comment #6 from Kenji Hara k.hara...@gmail.com --- *** Issue 3881 has been marked as a duplicate of this issue. *** --
[Issue 3881] Structs as template arguments
https://issues.dlang.org/show_bug.cgi?id=3881 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Kenji Hara k.hara...@gmail.com --- Fixed in 2.066. *** This issue has been marked as a duplicate of issue 8848 *** --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate, resulting in completely corrupt large values appearing
https://issues.dlang.org/show_bug.cgi?id=8621 --- Comment #7 from Gabor Mezo gabor.m...@outlook.com --- We have Still happens on git HEAD (v2.067-devel-cfe52d3) comment above. Maybe it only appears on Linux, or reappeared in v2.067. Worth a check before goes resolved. --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate, resulting in completely corrupt large values appearing
https://issues.dlang.org/show_bug.cgi?id=8621 --- Comment #8 from ent...@cantab.net --- True, I forgot that was there. For what it's worth, I originally encountered the bug on Windows. --
[Issue 13410] Performance problem with associative array byKey/byValue
https://issues.dlang.org/show_bug.cgi?id=13410 Ketmar Dark ket...@ketmar.no-ip.org changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #35 from Ketmar Dark ket...@ketmar.no-ip.org --- (In reply to Steven Schveighoffer from comment #34) This PR should have identical performance as your latest for the code in question, but not cause any slowdown for remove otherwise. sorry, i misread your patch (yes, i've looked at it before posting my answer). yet you doing a slightly different thing and i don't want to argue. that's why i'm saying that i don't care: both variants are good, and my own has some good points for my use cases. that's why i'm not interesting in defending my code — not that i don't care about changes or so. Hm... people here have made a lot of effort to work with your patch given your objections to github. i can't remember when i forced anybody to do anything with this patch. yet if somebody feels bad about it, he can ask for refund: i'll gladly return his money. Normally I would suggest that unless you submit a PR, you will not get this code included. i don't really care. i'm putting my patches here for those who interested and they are free to do anything they want with my code. i know that bugzilla patches have very little chance to be included in mainline. i just want to share my vision in the form of the code for others to decide. --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate, resulting in completely corrupt large values appearing
https://issues.dlang.org/show_bug.cgi?id=8621 Ketmar Dark ket...@ketmar.no-ip.org changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #9 from Ketmar Dark ket...@ketmar.no-ip.org --- just checked with HEAD-1d1998 on 32-bit GNU/Linux. first sample prints alot of '9', second sample prints alot of '0'. so it works at least for 32-bits. maybe this is 64-bit issue? --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate, resulting in completely corrupt large values appearing
https://issues.dlang.org/show_bug.cgi?id=8621 --- Comment #10 from ent...@cantab.net --- I think I was working in 32-bit though. hsteoh, can you tell us more about the situation you reproduced it in? --
[Issue 1327] Long environment variable value causes link failure.
https://issues.dlang.org/show_bug.cgi?id=1327 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added Priority|P2 |P1 CC||thecybersha...@gmail.com Component|DMD |Optlink Version|D1 |D1 D2 Severity|normal |critical --- Comment #4 from Vladimir Panteleev thecybersha...@gmail.com --- OPTLINK doesn't see the LIB variable if the environment is too big. In my case it starts to misbehave if the environment is longer than about 8K, but I guess the exact size varies depending on where LIB is in the environment. This affects D2 as well. --
[Issue 8621] Iteration variable in foreach not closed upon properly in delegate, resulting in completely corrupt large values appearing
https://issues.dlang.org/show_bug.cgi?id=8621 --- Comment #11 from hst...@quickfur.ath.cx --- Just retested it on Linux/64 (git HEAD), seems that garbage values are no longer happening. It still shows improper/missing closure over i, though, because the output is all 9's, meaning that it's closing on a single variable i shared across all iterations, as opposed to unique values per iteration. So basically the only bug left is issue #2043; the corrupted values Andrei reported seem to have been fixed since. --
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043
hst...@quickfur.ath.cx changed:
What|Removed |Added
CC||hst...@quickfur.ath.cx
--- Comment #13 from hst...@quickfur.ath.cx ---
Note that this bug breaks immutability:
-
import std.stdio;
void main() {
void delegate()[] a;
foreach (i; 1 .. 10) {
immutable j = i;
writeln(j);
a ~= { writeln(j); };
}
writeln(---);
foreach (f; a) {
f();
}
}
-
Output:
-
1
2
3
4
5
6
7
8
9
---
9
9
9
9
9
9
9
9
9
-
Notice that in each iteration of the loop, we are closing on the immutable
value j, which is set to the loop counter. However, the output shows that the
value of j has changed since the delegates were initialized. In fact, it
changes at every iteration. This violates the guarantee of immutable.
--
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043 --- Comment #14 from hst...@quickfur.ath.cx --- Note that the same thing applies if you make the loop counter immutable, which the compiler also readily accepts. But the delegates will all capture the same address which is reused over and over. So, basically, the logical scope of the loop counter i should be restricted to a *single* iteration (otherwise we must reject immutable loop counters!), but currently, its actual scope is the loop body *across* all iterations. The delegates exacerbate this problem by extending this scope even further, outside the loop body. Ideally, the compiler should allocate each new loop counter value on the heap, unless it can prove that there are no escaping references to it at the end of the iteration, in which case it is then safe to put it on the stack (and reuse the same memory for subsequent iterations). --
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043 --- Comment #15 from hst...@quickfur.ath.cx --- P.S., printing out the addresses of local variables outside the loop as well as the loop counter, reveals that if we comment out the line that initializes the delegates closing over the loop counter, then the loop counter is allocated on the stack, but with the closures, the compiler actually allocates the loop counter on the heap. However, it fails to recognize that multiple iterations of the loop will reuse the same heap variable. So it looks like the compiler is already halfway there; it's already detecting the closure and putting the loop counter on the heap instead of the stack. Now the only thing that remains, is for it to detect that it needs a new instance of the loop counter per iteration, as opposed to just a single instance. --
[Issue 13468] std.algorithm.canFind(null) fails with class
https://issues.dlang.org/show_bug.cgi?id=13468
--- Comment #3 from hst...@quickfur.ath.cx ---
Workaround:
Instead of using the default predicate a==b with null (i.e., effectively a
== null), use this instead:
if (canFind!a is null(b)) { ... }
--
[Issue 13468] std.algorithm.canFind(null) fails with class
https://issues.dlang.org/show_bug.cgi?id=13468
--- Comment #4 from hst...@quickfur.ath.cx ---
Alternate syntax:
if (canFind!((a) = a is null)(b)) { ... }
--
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043
--- Comment #16 from ent...@cantab.net ---
Unfortunately I have a feeling there will be people relying on being able to do
this kind of thing (though I'm not 100% sure if it currently works):
foreach (i; 0..10) {
...
if (somethingStrangeHappens) {
//Try again with the same 'i'
i--;
continue;
}
}
If 'i' became a new variable for each iteration, then the modify-assign would
not have the effect intended. Do we need to make 'i' implicitly final to
protect against this?
--
[Issue 13468] std.algorithm.canFind(null) fails with class
https://issues.dlang.org/show_bug.cgi?id=13468
hst...@quickfur.ath.cx changed:
What|Removed |Added
Keywords||wrong-code
Component|Phobos |DMD
--- Comment #5 from hst...@quickfur.ath.cx ---
Apparently I made a total fool of myself. The *real* reason for the bug is not
a.opEquals(b), but is caused by using == to compare a class reference to an
instance of typeof(null).
Specifically, this code works:
--
class C { }
bool fun(C e, C needle)
{
return (e == needle);
}
void main()
{
fun(null, null);
}
--
But this code segfaults:
--
class C { }
bool fun(C e, typeof(null) needle)
{
return (e == needle);
}
void main()
{
fun(null, null);
}
--
The only difference is that the segfaulting case takes `typeof(null)` as
parameter. Comparing class references with null is actually OK; what's *not* OK
is comparing them with an instance of typeof(null). I think this is a compiler
bug.
--
[Issue 13468] Wrong code when comparing class reference with typeof(null)
https://issues.dlang.org/show_bug.cgi?id=13468 hst...@quickfur.ath.cx changed: What|Removed |Added Summary|std.algorithm.canFind(null) |Wrong code when comparing |fails with class|class reference with ||typeof(null) --
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043
Ketmar Dark ket...@ketmar.no-ip.org changed:
What|Removed |Added
CC||ket...@ketmar.no-ip.org
--- Comment #17 from Ketmar Dark ket...@ketmar.no-ip.org ---
(In reply to entheh from comment #16)
i believe that modifying `i` should be allowed here. but without 'ref' `i` is a
copy of internal counter, so your sample correctly iterates 10 times, updating
`i` to correct value on each iteration. but this works (and it's correct too):
foreach (ref i; 0..10) {
++i; // skip one
writeln(i);
}
this outputs 1, 3, 5, 7, 9.
If 'i' became a new variable for each iteration, then the modify-assign
would not have the effect intended.
it works this way now. ;-)
--
[Issue 2043] Closure outer variables in nested blocks are not allocated/instantiated correctly: should have multiple instances but only have one.
https://issues.dlang.org/show_bug.cgi?id=2043 --- Comment #18 from hst...@quickfur.ath.cx --- If the loop index is mutable, then I think it's OK to make it shared across loop iterations. Creating a new instance of a loop variable per iteration is only necessary if (1) the loop index is immutable, and (2) it is being closed over. (I also think modifying the loop counter of a foreach loop is a very bad idea -- you should be using a good ole for(...) loop or while loop instead -- but that's beside the point.) --
[Issue 13468] Wrong code when comparing class reference with typeof(null)
https://issues.dlang.org/show_bug.cgi?id=13468 --- Comment #6 from hst...@quickfur.ath.cx --- Looking at the disassembly, in the first (working) case, Object.opEquals() is called directly. In the second (segfaulting) case, it appears to be doing a lookup of the vtable (or perhaps typeinfo?) of either C or typeof(null) and dereferencing it without checking for null. --
[Issue 9891] Ability to modify immutable using default value of ref/out parameter
https://issues.dlang.org/show_bug.cgi?id=9891 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --- Comment #1 from hst...@quickfur.ath.cx --- Still happens on git HEAD (b7ace0b93bb1...). --
[Issue 13349] [Mago] Wrong breakpoint locations in v0.3.39-beta2
https://issues.dlang.org/show_bug.cgi?id=13349 --- Comment #10 from Rainer Schuetze r.sagita...@gmx.de --- (In reply to Denis Shelomovskij from comment #8) As I wrote: Sometimes half of module lines background is filled when setting a single breakpoint (before and after the breakpoint) Sorry, I wasn't reading carefully enough, I guess. So the breakpoint line is still sometimes located before actual breakpoint. Sorry, it wasn't shown in the testcase. Will create a new one. Thanks for the new test case, please try the fix for it here: https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.39-rc2 --
[Issue 13349] [Mago] Wrong breakpoint locations in v0.3.39-beta2
https://issues.dlang.org/show_bug.cgi?id=13349 Denis Shelomovskij verylonglogin@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Denis Shelomovskij verylonglogin@gmail.com --- (In reply to Rainer Schuetze from comment #10) snip Thanks for the new test case, please try the fix for it here: https://github.com/D-Programming-Language/visuald/releases/tag/v0.3.39-rc2 Thanks, it works now. ) --
[Issue 11811] Add eval to phobos
https://issues.dlang.org/show_bug.cgi?id=11811 hst...@quickfur.ath.cx changed: What|Removed |Added CC||hst...@quickfur.ath.cx --
[Issue 11811] Add eval to phobos
https://issues.dlang.org/show_bug.cgi?id=11811 --- Comment #3 from hst...@quickfur.ath.cx --- Yeah, I think ctEval is a better name, otherwise people could misunderstand it as runtime mixin, as it is used in other languages. --
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448 --- Comment #6 from github-bugzi...@puremagic.com --- Commit pushed to master at https://github.com/D-Programming-Language/dlang.org https://github.com/D-Programming-Language/dlang.org/commit/2ab88c406b4b8077d8709f61ea14af43148c9b72 Merge pull request #655 from quickfur/issue13448 Base classes / interfaces may be template instantiations too. --
[Issue 10233] [Tracker] Grammar issues
https://issues.dlang.org/show_bug.cgi?id=10233 Issue 10233 depends on issue 13448, which changed state. Issue 13448 Summary: Class specification misses template classes in base classes list https://issues.dlang.org/show_bug.cgi?id=13448 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13448] Class specification misses template classes in base classes list
https://issues.dlang.org/show_bug.cgi?id=13448 hst...@quickfur.ath.cx changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
