[Issue 12009] local import and unable to resolve forward reference error
https://d.puremagic.com/issues/show_bug.cgi?id=12009 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2014-04-02 23:04:59 PDT --- https://github.com/D-Programming-Language/dmd/pull/3418 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5240] Faster std.random.uniform() for [0.0, 1.0) range
https://d.puremagic.com/issues/show_bug.cgi?id=5240 --- Comment #7 from github-bugzi...@puremagic.com 2014-04-02 23:34:23 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/d0727dc7a02a33d855cc141f09f883501077797b Fix Issue #5240: faster std.random.uniform for [0.0, 1.0) range Following typical design in other languages, the function is named uniform01. It can be templated on floating-point type, defaulting to double if none is specified. The implementation is pretty much derived from its counterpart in Boost.Random, in particular in its taking account of the different requirements for integral versus floating-point RNG values, and in checking that the generated variate is less than 1 before returning. This last check is necessary simply because we can't guarantee, in the case of a floating-point based RNG, that we will not get a result exactly equal to 1. Fixes http://d.puremagic.com/issues/show_bug.cgi?id=5240 https://github.com/D-Programming-Language/phobos/commit/0ba2004bd4d725c5ccff227a65bc19a6e3371381 Merge pull request #2050 from WebDrake/uniform01 Fix Issue #5240: faster std.random.uniform for [0.0, 1.0) range -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12506] Wrongly private lambda to define global immutable array
https://d.puremagic.com/issues/show_bug.cgi?id=12506 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull Platform|x86 |All OS/Version|Windows |All --- Comment #1 from Kenji Hara k.hara...@gmail.com 2014-04-03 00:21:59 PDT --- https://github.com/D-Programming-Language/dmd/pull/3419 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12510] New: Templated overload ignored
https://d.puremagic.com/issues/show_bug.cgi?id=12510
Summary: Templated overload ignored
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: jmdavisp...@gmx.com
--- Comment #0 from Jonathan M Davis jmdavisp...@gmx.com 2014-04-03 00:26:37
PDT ---
This code results in infinite recursion:
class C
{
bool foo(C rhs)
{
return false;
}
}
bool foo(T, U)(T lhs, U rhs)
if (is(T == class) is(U == class)
is(typeof(lhs.foo(rhs)) == bool)
is(typeof(rhs.foo(lhs)) == bool))
{
return true;
}
bool foo()(const C lhs, const C rhs)
{
return foo(cast()lhs, cast()rhs);
}
void main()
{
const C a = new C;
const C b = new C;
auto d = foo(a, b);
}
And whether a and b are const or not doesn't matter. The first overload is
simply never called. It always calls the second overload. And making it so that
the second overload isn't templatized has no effect. It used to be that this
would compile, because it was working in this pull request:
https://github.com/D-Programming-Language/druntime/pull/459
whereas that pull request now results in infinite recursion.
I'd have to try it on several older versions of dmd though to figure out when
it broke, but this definitely worked before. My first guess is that it broke
when it was fixed so that templated and non-template functions could be
overloaded.
The fact that the first overload fails with const objects should force them to
use the second overload (because C.foo isn't const), whereas if they're not
const, then the first should match better than the second. And to make matters
worse, if I change the code to
class C
{
bool foo(C rhs)
{
return false;
}
}
bool foo(T, U)(T lhs, U rhs)
{
return true;
}
bool foo()(const C lhs, const C rhs)
{
return foo(cast()lhs, cast()rhs);
}
void main()
{
const C a = new C;
const C b = new C;
auto d = foo(a, b);
}
it still compiles with the same result, whereas it _should_ result in a
compilation error due to ambiguity, because both functions match equally well.
Instead, the second function is always called, whether it's templatized or not
and whether the arguments are const or not.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12511] New: static overloaded function is not accessible
https://d.puremagic.com/issues/show_bug.cgi?id=12511
Summary: static overloaded function is not accessible
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: do.m...@foxmail.com
--- Comment #0 from Domain do.m...@foxmail.com 2014-04-03 01:05:34 PDT ---
module A;
public class A {
private static void foo() {}
public static void foo(int) {}
}
module B;
import A;
public class B {
public static void bar() { A.foo(0); }
}
Error: class A.A member foo is not accessible
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12510] Templated overload ignored
https://d.puremagic.com/issues/show_bug.cgi?id=12510
Martin Nowak c...@dawg.eu changed:
What|Removed |Added
CC||c...@dawg.eu
--- Comment #1 from Martin Nowak c...@dawg.eu 2014-04-03 01:16:47 PDT ---
I think this might be the result of bug 1528. Not sure, but I think the empty
template arguments are matched with MATCHexact, just like a plain function
declaration. And subsequently converting both function arguments to const is
deemed a better match than the template.
You can use this instead.
bool foo (const C lhs, const C rhs)
{
foo!(C, C)(cast()lhs, cast()rhs);
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12510] Templated overload ignored
https://d.puremagic.com/issues/show_bug.cgi?id=12510
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
--- Comment #2 from Kenji Hara k.hara...@gmail.com 2014-04-03 01:36:24 PDT ---
(In reply to comment #1)
I think this might be the result of bug 1528. Not sure, but I think the empty
template arguments are matched with MATCHexact, just like a plain function
declaration. And subsequently converting both function arguments to const is
deemed a better match than the template.
You can use this instead.
bool foo (const C lhs, const C rhs)
{
foo!(C, C)(cast()lhs, cast()rhs);
}
Yes, this is correct result caused by fixing issue 1528.
Another way is to supply specialized foo for const C parameters, like as:
bool foo(T:Object, U:Object)(const T lhs, const U rhs)
{
return foo(cast()lhs, cast()rhs);
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12499] tuple/TypeTuple 1-Arg initialization fails during CTFE.
https://d.puremagic.com/issues/show_bug.cgi?id=12499 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, rejects-valid Version|unspecified |D2 --- Comment #1 from Kenji Hara k.hara...@gmail.com 2014-04-03 02:28:40 PDT --- https://github.com/D-Programming-Language/dmd/pull/3420 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12512] New: Feature request: cdup
https://d.puremagic.com/issues/show_bug.cgi?id=12512
Summary: Feature request: cdup
Product: D
Version: unspecified
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: monarchdo...@gmail.com
--- Comment #0 from monarchdo...@gmail.com 2014-04-03 02:39:36 PDT ---
Request for cdup. Because some const types just can't be cast to either
mutable or immutable.
//
struct S{int*p;}
void main()
{
const(S)[] s;
s.dup; //Nope
s.idup; //Nope
s.cdup; //I'd like this.
}
//
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12505] Null pointers are pretty-printed even when hex output is requested
https://d.puremagic.com/issues/show_bug.cgi?id=12505 Vladimir Panteleev thecybersha...@gmail.com changed: What|Removed |Added CC||thecybersha...@gmail.com --- Comment #2 from Vladimir Panteleev thecybersha...@gmail.com 2014-04-03 13:22:16 EEST --- Introduced in https://github.com/D-Programming-Language/phobos/pull/298 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12505] Null pointers are pretty-printed even when hex output is requested
https://d.puremagic.com/issues/show_bug.cgi?id=12505 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull, wrong-code --- Comment #3 from Kenji Hara k.hara...@gmail.com 2014-04-03 03:47:43 PDT --- https://github.com/D-Programming-Language/phobos/pull/2068 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12512] Feature request: cdup
https://d.puremagic.com/issues/show_bug.cgi?id=12512 yebblies yebbl...@gmail.com changed: What|Removed |Added CC||yebbl...@gmail.com --- Comment #1 from yebblies yebbl...@gmail.com 2014-04-03 21:58:26 EST --- Shouldn't dup just give you const(T)[] when it can't manage T[] ? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12512] Feature request: cdup
https://d.puremagic.com/issues/show_bug.cgi?id=12512 --- Comment #2 from monarchdo...@gmail.com 2014-04-03 04:09:21 PDT --- (In reply to comment #1) Shouldn't dup just give you const(T)[] when it can't manage T[] ? That would also work for me I guess. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12498] ICE: while(string) causes compiler to crash during CTFE
https://d.puremagic.com/issues/show_bug.cgi?id=12498 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com 2014-04-03 04:27:52 PDT --- https://github.com/D-Programming-Language/dmd/pull/3422 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5240] Faster std.random.uniform() for [0.0, 1.0) range
https://d.puremagic.com/issues/show_bug.cgi?id=5240 bearophile_h...@eml.cc changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12505] Null pointers are pretty-printed even when hex output is requested
https://d.puremagic.com/issues/show_bug.cgi?id=12505 --- Comment #4 from github-bugzi...@puremagic.com 2014-04-03 04:41:06 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/b52649ab8ba652e82ae3fe39c9c0ce2a28829465 fix Issue 12505 - Null pointers are pretty-printed even when hex output is requested https://github.com/D-Programming-Language/phobos/commit/c9666fb102cc46fb6d3255fbf867bc90a41c58be Merge pull request #2068 from 9rnsr/fix12505 Issue 12505 - Null pointers are pretty-printed even when hex output is requested -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11778] format for null does not verify fmt flags.
https://d.puremagic.com/issues/show_bug.cgi?id=11778 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #4 from Kenji Hara k.hara...@gmail.com 2014-04-03 04:51:24 PDT --- https://github.com/D-Programming-Language/phobos/pull/2069 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12505] Null pointers are pretty-printed even when hex output is requested
https://d.puremagic.com/issues/show_bug.cgi?id=12505 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12498] ICE: while(string) causes compiler to crash during CTFE
https://d.puremagic.com/issues/show_bug.cgi?id=12498 --- Comment #3 from github-bugzi...@puremagic.com 2014-04-03 05:47:58 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fa9efd8a5e9df74209c3957ab2f15c834a8a798c fix Issue 12498 - ICE: while(string) causes compiler to crash during CTFE https://github.com/D-Programming-Language/dmd/commit/2c4d8ad711ccb7c94d349830523dd500580b0130 Merge pull request #3422 from 9rnsr/fix12498 Issue 12498 - ICE: while(string) causes compiler to crash during CTFE -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12513] New: std.file: dirEntries-range crashes, when hitting the system folder System Volume Information
https://d.puremagic.com/issues/show_bug.cgi?id=12513
Summary: std.file: dirEntries-range crashes, when hitting the
system folder System Volume Information
Product: D
Version: D2
Platform: All
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: chris...@schardt.info
--- Comment #0 from Christof Schardt chris...@schardt.info 2014-04-03
05:56:21 PDT ---
ca. line +-2590 in std.file.d
bool stepIn(string directory)
{
string search_pattern = buildPath(directory, *.*);
WIN32_FIND_DATAW findinfo;
-- HANDLE h = FindFirstFileW(toUTF16z(search_pattern), findinfo);
-- cenforce(h != INVALID_HANDLE_VALUE, directory);
}
The cenforce() throws, when the folder System Volume Information is handled.
But this folder results in an INVALID HANDLE VALUE.
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12498] ICE: while(string) causes compiler to crash during CTFE
https://d.puremagic.com/issues/show_bug.cgi?id=12498 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6946] Compile-time flags generator
https://d.puremagic.com/issues/show_bug.cgi?id=6946
--- Comment #9 from Nick Treleaven ntrel-pub...@yahoo.co.uk 2014-04-03
07:43:21 PDT ---
(In reply to comment #8)
Is the name MyFlags not useful (as shown in the syntax you quote)?
It's fine, I just thought it might be good to take advantage of a mixin
identifier (I often forget about that feature). It seems a bit cleaner to me
than a string argument, although having mixin assignment syntax would make this
clearer. Nice idea BTW.
The cleanness is because I like to have identifiers highlighted in the same way
rather than have some as strings, so I would prefer to read something like:
mixin BitFlags!q{A, B, C, D} MyFlags;
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 11778] format for null does not verify fmt flags.
https://d.puremagic.com/issues/show_bug.cgi?id=11778 --- Comment #5 from github-bugzi...@puremagic.com 2014-04-03 08:01:42 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/b32e4032c1adbdabd4cdcfe3599606d806762038 fix Issue 11778 - format for null does not verify fmt flags. https://github.com/D-Programming-Language/phobos/commit/f8288c7ea321cfee94561f70a64fc01f81c7ae10 Merge pull request #2069 from 9rnsr/fix11778 Issue 11778 - format for null does not verify fmt flags. -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6946] Compile-time flags generator
https://d.puremagic.com/issues/show_bug.cgi?id=6946 --- Comment #10 from bearophile_h...@eml.cc 2014-04-03 09:07:50 PDT --- (In reply to comment #9) although having mixin assignment syntax would make this clearer. Nice idea BTW. The point of giving it a name in some way (with a string) is because later you can use some trait to ask for its name. I am not suer how important this is. The idea comes from Python namedtuples: from collections import namedtuple Three = namedtuple(Two, a b) Three(1, 2) Two(a=1, b=2) -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 6946] Compile-time flags generator
https://d.puremagic.com/issues/show_bug.cgi?id=6946
--- Comment #11 from bearophile_h...@eml.cc 2014-04-03 09:49:38 PDT ---
(In reply to comment #10)
The cleanness is because I like to have identifiers highlighted in the same
way
rather than have some as strings, so I would prefer to read something like:
mixin BitFlags!q{A, B, C, D} MyFlags;
Is your version using a function like isReservedWord() I have shown in the
first posts here?
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 9112] Uniform construction for built-in types
https://d.puremagic.com/issues/show_bug.cgi?id=9112
--- Comment #32 from bearophile_h...@eml.cc 2014-04-03 10:11:17 PDT ---
Unfortunately the syntax doesn't work for fixed-size arrays:
void foo(T, size_t N)(T[N] x) {
pragma(msg, T);
}
void main() {
uint x = 1_000;
foo([x % 3, x % 200]); // OK, uint
foo(cast(ubyte[2])[x % 3, x % 200]); // OK, ubyte
ubyte[2] aux = [x % 3, x % 200];
foo(aux);// OK, ubyte
foo(ubyte[2]([x % 3, x % 200])); // error
}
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12514] New: Value range analysis in triple operator too
https://d.puremagic.com/issues/show_bug.cgi?id=12514
Summary: Value range analysis in triple operator too
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2014-04-03 10:41:04 PDT ---
Value range analysis could be extended to cover this case too:
void main() {
ulong x = 10_000_000;
uint y = (x = uint.max) ? x : 0;
}
dmd 2.066alpha gives:
test.d(3,14): Error: cannot implicitly convert expression (x = 4294967295LU ?
x : 0LU) of type ulong to uint
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12515] New: memchr/wmemchr/dmemchr in druntime
https://d.puremagic.com/issues/show_bug.cgi?id=12515 Summary: memchr/wmemchr/dmemchr in druntime Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: monarchdo...@gmail.com --- Comment #0 from monarchdo...@gmail.com 2014-04-03 14:01:53 PDT --- This is a request to have a trio of functions in druntime, that do what memchr does, but also for 1-byte, 2-byte and 4-byte widths (and maybe 8 bytes too). The issue with C's wmemchr is that works on `wchar_t`, which may be either a wchar or dchar, making it horribly difficult to use in a generic way (or at all). Having these methods in druntime would be able to do memory wise search in a much easier fashion. It would also have the advantage of: - accept a const(void)[] as input, so using them is just safe. - have a __ctfe branch, so no special branches need to be deployed by the caller: It just works. Not sure which druntime (or phobos?) library it would go into. Also, a rename might help, to avoid ambiguity [cwdl]memsearch? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12515] memchr/wmemchr/dmemchr in druntime
https://d.puremagic.com/issues/show_bug.cgi?id=12515 Andrej Mitrovic andrej.mitrov...@gmail.com changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic andrej.mitrov...@gmail.com 2014-04-03 23:20:26 CEST --- Speaking of which, will this be reopened? https://github.com/D-Programming-Language/phobos/pull/1665 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11025] [aa] std.typecons.Tuple needs to define toHash
https://d.puremagic.com/issues/show_bug.cgi?id=11025 David Spies dsp...@ualberta.ca changed: What|Removed |Added CC||dsp...@ualberta.ca Severity|normal |major --- Comment #1 from David Spies dsp...@ualberta.ca 2014-04-03 15:44:34 PDT --- This seems really serious. It's undocumented, unexpected, and the source of completely untraceable bugs. It applies not just to Tuple, but to the default hash for any user-defined structs. Should this bug be elevated to major or even critical (at least until it's documented on the AA page)? -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12516] New: TypeInfo.getHash should not be trusted
https://d.puremagic.com/issues/show_bug.cgi?id=12516
Summary: TypeInfo.getHash should not be trusted
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: nob...@puremagic.com
ReportedBy: dsp...@ualberta.ca
--- Comment #0 from David Spies dsp...@ualberta.ca 2014-04-03 16:11:53 PDT ---
When getHash is overridden, it may try to dereference the void pointer, so it's
not safe if the pointer is to the wrong type.
import std.string;
static int x = 35873;
@safe
void main() {
typeid(string).getHash(x);
}
---
An example program which segfaults within a @safe method
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 12078] forward reference issue with is() and curiously recurring template pattern
https://d.puremagic.com/issues/show_bug.cgi?id=12078 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #2 from Kenji Hara k.hara...@gmail.com 2014-04-03 19:36:11 PDT --- https://github.com/D-Programming-Language/dmd/pull/3384 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 12143] Base class is forward referenced
https://d.puremagic.com/issues/show_bug.cgi?id=12143 Kenji Hara k.hara...@gmail.com changed: What|Removed |Added Keywords||pull --- Comment #1 from Kenji Hara k.hara...@gmail.com 2014-04-03 19:36:18 PDT --- https://github.com/D-Programming-Language/dmd/pull/3384 -- Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 11777] [ICE] dmd memory corruption as `Scope::pop` `free`s `fieldinit` used also in `enclosing`
https://d.puremagic.com/issues/show_bug.cgi?id=11777
Kenji Hara k.hara...@gmail.com changed:
What|Removed |Added
Keywords||pull
--- Comment #12 from Kenji Hara k.hara...@gmail.com 2014-04-03 22:19:15 PDT
---
(In reply to comment #10)
Let's add `assert(fieldinit != enclosing-fieldinit);` in `Scope::pop` before
we `free(fieldinit)`. This code fails the assertion (and `nofree` is `false`):
---
void f(void delegate(int)) { }
class C
{
int i;
this() { f((a) {}); }
}
---
Thanks for your work and shrunken test case! It was much helpful for me.
https://github.com/D-Programming-Language/dmd/pull/3423
--
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
