[Issue 13952] [REG2.067a] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 13952] [REG2.067a] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952 --- Comment #8 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/e5f21beb82acade73900aa50a0e092b3935e980b fix Issue 13952 - change in struct ctor lowering triggers codegen bug https://github.com/D-Programming-Language/dmd/commit/2ebb60303208768adfa29d29f11f7fc8c95fffa7 Merge pull request #4387 from 9rnsr/fix13952 [REG2.067a] Issue 13952 - change in struct ctor lowering triggers codegen bug --
[Issue 14138] std.parallelism.task breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14138 David Nadlinger changed: What|Removed |Added Severity|enhancement |major --
[Issue 14138] New: std.parallelism.task breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14138
Issue ID: 14138
Summary: std.parallelism.task breaks @safety
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: safe
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: c...@klickverbot.at
---
struct Oops {
int convert() {
*cast(int*)0xcafebabe = 0xdeadbeef;
return 0;
}
alias convert this;
}
void main() @safe {
import std.parallelism;
static void foo(int) @safe {}
auto t = task(&foo, Oops.init);
// or: auto t = scopedTask(&foo, Oops.init);
taskPool.put(t);
}
---
Tested with current Git master (4de96a06, to-be 2.067), but looks like the
issues has been present since the initial merge of std.parallelism.
Again a case of @trusted used on a template function without sufficient
constraints.
--
[Issue 14137] New: std.socket.getAddressInfo breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14137
Issue ID: 14137
Summary: std.socket.getAddressInfo breaks @safety
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: safe
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: c...@klickverbot.at
---
struct Oops {
const(char[]) convert() {
*cast(int*)0xcafebabe = 0xdeadbeef;
return null;
}
alias convert this;
}
void main() @safe {
import std.socket;
getAddressInfo("", Oops.init);
}
---
Seems to be Git master (to-be 2.067) only.
Source permalink:
https://github.com/D-Programming-Language/phobos/blob/master/std/socket.d#L996-L997
Introduced in https://github.com/D-Programming-Language/phobos/pull/2316.
--
[Issue 14135] std.uuid.randomUUID breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 David Nadlinger changed: What|Removed |Added Summary|std.uuid.randomUUID |std.uuid.randomUUID breaks |violates breaks @safety |@safety --
[Issue 14136] New: std.uni.utfMatcher breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14136
Issue ID: 14136
Summary: std.uni.utfMatcher breaks @safety
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: safe
Severity: enhancement
Priority: P1
Component: Phobos
Assignee: nob...@puremagic.com
Reporter: c...@klickverbot.at
---
struct Oops {
pure:
bool empty() {
*cast(int*)0xcafebabe = 0xdeadbeef;
return true;
}
Oops save() @property { return this; }
char front;
void popFront() {}
char back;
void popBack() {}
ref char opIndex(size_t idx) { return front; }
enum size_t length = 0;
alias opDollar = length;
}
void main() @safe {
import std.uni;
auto m = utfMatcher!char(unicode.Number);
Oops o;
m.match(o);
}
---
Again, the reason is a @trusted template function taking an arbitrary range.
Source permalink (other match variants are affected too):
https://github.com/D-Programming-Language/phobos/blob/041db2d8fac2b1cf5169be7188ea537a01f27586/std/uni.d#L4767-L4787
Introduced in https://github.com/D-Programming-Language/phobos/pull/2020.
--
[Issue 14135] std.uuid.randomUUID violates breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 --- Comment #1 from David Nadlinger --- Source permalink for your convenience: https://github.com/D-Programming-Language/phobos/blob/041db2d8fac2b1cf5169be7188ea537a01f27586/std/uuid.d#L1061-L1086 --
[Issue 14135] New: std.uuid.randomUUID violates breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 Issue ID: 14135 Summary: std.uuid.randomUUID violates breaks @safety Product: D Version: D2 Hardware: x86_64 OS: All Status: NEW Severity: major Priority: P1 Component: websites Assignee: nob...@puremagic.com Reporter: c...@klickverbot.at The @trusted UUID randomUUID(RNG)(ref RNG randomGen) if(isIntegral!(typeof(RNG.front))) overload is incorrectly marked as @trusted, as the user might pass a custom RNG with @system range primitives. Seems like it was introduced in https://github.com/D-Programming-Language/phobos/pull/1708. --
[Issue 14135] std.uuid.randomUUID violates breaks @safety
https://issues.dlang.org/show_bug.cgi?id=14135 David Nadlinger changed: What|Removed |Added Keywords||safe --
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 --- Comment #8 from Rainer Schuetze --- Other notes: - The current version also "works" for memory allocated outside the GC, it just doesn't free the memory. - The current version "works" for manually allocated arrays (e.g. Appender). >So if the code stays as it is, our promoted method of destroying an array is >no good. There is no good way to destroy an array except delete. What is the "proposed method"? Using GC.free(arr.ptr)? --
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 --- Comment #7 from Rainer Schuetze --- Checking the code from 2.066 again, it corrupts memory - if the array.ptr offset from the base pointer in a small allocation is larger than 15 bytes - if the array.ptr offset from the base pointer in a large allocation is larger than 4095 bytes. So apart from some rather obscure indices above 0, but below some threshold, only passing the array base pointer actually worked. Making other pointers raise an error seems an improvement. For a partial length, it didn't make much of a difference unless struct destructors have to be called. Not calling all of them is very probably an error, too. Informing the user about this with an error should be ok. This leaves the case when a wrong size didn't cause any issues. An error could be considered annoying, so maybe we could relax option 3 a little for types without destructor. --
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134
--- Comment #6 from Steven Schveighoffer ---
(In reply to Rainer Schuetze from comment #5)
> Maybe we should relax the restriction on base pointers for free().
>
> What should happen with code like this?
>
>struct S { ~this() { printf("~this\n"); } int x; }
>
>S[] arr = new S[1000];
>S[] slice = arr[100..200];
>S[] tail = arr[200..1000];
>delete slice;
>
> Should it call call only 100 destructors? All 1000? Is this invalid code?
Good question. I would tend to think that there are several right answers:
1. Destroy entire array.
2. Destroy only the slice, do not run dtors on the head or tail
3. Error, must delete entire array
4. Do nothing (and don't free the array).
Wrong thing to do would be run destructor on slice and run it again when the
memory is freed.
My preference is for option 3, but that may be too heavy handed.
--
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134
--- Comment #5 from Rainer Schuetze ---
Maybe we should relax the restriction on base pointers for free().
What should happen with code like this?
struct S { ~this() { printf("~this\n"); } int x; }
S[] arr = new S[1000];
S[] slice = arr[100..200];
S[] tail = arr[200..1000];
delete slice;
Should it call call only 100 destructors? All 1000? Is this invalid code?
Calling dtors twice could be fixed by explicitely removing the FINALIZE
attribute from the block, but could not work for just a part of the array.
--
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 --- Comment #4 from Steven Schveighoffer --- (In reply to Steven Schveighoffer from comment #3) > 1. When we say new T[x], we get a pointer not to the point of the block ... not to the *front* of the block --
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 --- Comment #3 from Steven Schveighoffer --- OK, so I have a problem with the current code: 1. When we say new T[x], we get a pointer not to the point of the block 2. delete is supposedly going to be deprecated. So if the code stays as it is, our promoted method of destroying an array is no good. There is no good way to destroy an array except delete. I think we definitely should fix _d_delarray_t, as dtors should not be called more than once, and to have it not free the data is bad. But I think we need some way of saying this block can still be freed because even though it's not the base pointer, the data before the pointer is owned by the runtime, and invisible to the user. And I really think that should be done in GC.free. --
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 --- Comment #2 from Rainer Schuetze --- I admit there is a problem in _d_delarray_t which is called for "delete array;". Should it free the whole block instead using GC.query.base? What if the array is just a slice of a larger array? --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #19 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/druntime https://github.com/D-Programming-Language/druntime/commit/21aba9efeaf9eacd7da3d2585519b083355b9b78 Fixed issue 14126 -- Used wrong constant for offset when finalizing a large array. https://github.com/D-Programming-Language/druntime/commit/1c5aef8b9d58718b633d2a45ca09b5f9dd1ab6bc Merge pull request #1159 from schveiguy/issue14126 Fixed issue 14126 -- GC seemingly corrupting memory --
[Issue 14134] Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 Rainer Schuetze changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #1 from Rainer Schuetze --- That was a bug in 2.066. Contrary to the documentation free() didn't really check whether a pointer is to the base of the allocation, and this could seriously corrupt the internal data structures. The check now is better, but still not perfect. The GC cannot easily determine whether a small allocation is already free'd or not. > If I use delete on that array, and it's an array of structs, it will call the > dtor twice on that array. The new struct destruction by the GC assumes that, if you manually call the destructor, you also take care of manually freeing the memory with GC.free. That way the GC will not call the destructor again. --
[Issue 14134] New: Free of large array does not work
https://issues.dlang.org/show_bug.cgi?id=14134 Issue ID: 14134 Summary: Free of large array does not work Product: D Version: D2 Hardware: x86 OS: All Status: NEW Severity: regression Priority: P1 Component: druntime Assignee: nob...@puremagic.com Reporter: schvei...@yahoo.com If I use GC.free on a large array of data, it is not freed. example: auto x = new int[1]; GC.free(x.ptr); assert(GC.addrOf(x.ptr) == null); // fails The last line works in 2.066.1 If I use delete on that array, and it's an array of structs, it will call the dtor twice on that array. Note that x.ptr is an interior pointer because of the array padding. I'm not sure if the old GC took this into account or what, but it seems to work. --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #18 from Ketmar Dark --- hm. i should start reading the whole file at least once before suggesting "improvements" that were already done. ;-) --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #17 from Steven Schveighoffer --- (In reply to Ketmar Dark from comment #15) > thank you for your explanation. maybe it can be written somewhere in source > code as comment, so people reading the sources have their question answered > even before they asked it? ;-) https://github.com/schveiguy/druntime/blob/issue14126/src/rt/lifetime.d#L235 Been there since I added it 5 years ago :) --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #16 from Steven Schveighoffer --- https://github.com/D-Programming-Language/druntime/pull/1159 --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #15 from Ketmar Dark --- thank you for your explanation. maybe it can be written somewhere in source code as comment, so people reading the sources have their question answered even before they asked it? ;-) --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com Assignee|nob...@puremagic.com|schvei...@yahoo.com --- Comment #14 from Steven Schveighoffer --- (In reply to Ketmar Dark from comment #11) > seems that the bug is due to the code in `lifetime.d:finalize_array2()`. > > for big blocks (those which are bigger or equal to PAGESIZE), it does this: > `p += LARGEPAD;`, and LARGEPAD is: > > LARGEPREFIX = 16, // 16 bytes padding at the front of the array > LARGEPAD = LARGEPREFIX + 1, > > seems that LARGEPAD must be used only in overall block size calculations, > but not as real padding (real padding is LARGEPREFIX in this case). > > yet i'm not an expert in D memory management, so i can't say if i'm really > right here. fixing `lifetime.d:finalize_array2()` to use `LARGEPREFIX` > instead seems to fix the bug. and hey, why anoyone would use 17-byte PREFIX > padding anyway? This is exactly the problem. The + 1 is used to determine overall size of array allocation. The +1 is the sentinel byte added to the end of the block to prevent cross-block referencing. For example, imagine you had a block of 16 bytes: ubyte[] x = new ubyte[16]; If you put this into an exact block of 16 bytes, then did this: x = x[$..$]; Now x.ptr is technically referring to the NEXT block in memory. That's why the sentinel is used. For smaller blocks, the sentinel is really the array 'used' size, but for larger blocks that can be extended, we put the 'used' size at the beginning. The resulting data must be 16-byte aligned, so we skip ahead 16 bytes (LARGEPREFIX), and we add 1 byte to the end to prevent cross-block issues. I will generate a PR. --
[Issue 14130] [REG2.067a] ICE following error in template parameter default value
https://issues.dlang.org/show_bug.cgi?id=14130 github-bugzi...@puremagic.com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --
[Issue 14130] [REG2.067a] ICE following error in template parameter default value
https://issues.dlang.org/show_bug.cgi?id=14130 --- Comment #2 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/5dd31fa1a3118e7cd522e6a3400957b31ecbed71 fix Issue 14130 - ICE following error in template parameter default value https://github.com/D-Programming-Language/dmd/commit/f51b7bb77de736bce051b1c1556b17e53e51b99f Merge pull request #4386 from 9rnsr/fix14130 [REG2.067a] Issue 14130 - ICE following error in template parameter default value --
[Issue 14059] Formatted write with wrong formatting string
https://issues.dlang.org/show_bug.cgi?id=14059 sinkuup...@gmail.com changed: What|Removed |Added Status|NEW |RESOLVED CC||sinkuup...@gmail.com Hardware|x86 |All Resolution|--- |FIXED OS|Windows |All --
[Issue 14059] Formatted write with wrong formatting string
https://issues.dlang.org/show_bug.cgi?id=14059 --- Comment #1 from github-bugzi...@puremagic.com --- Commits pushed to master at https://github.com/D-Programming-Language/phobos https://github.com/D-Programming-Language/phobos/commit/806361692978e538ed782287d796e58b2ed5b8df Issue 14059 - Formatted write with wrong formatting string https://github.com/D-Programming-Language/phobos/commit/3299c63e7500e6eeb9f5f3c9f8f3ec501fde6064 Merge pull request #2958 from sinkuu/fix_14059_format Issue 14059 - Formatted write with wrong formatting string --
[Issue 13952] [REG2.067a] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952 --- Comment #7 from Kenji Hara --- (In reply to Kenji Hara from comment #6) > (In reply to Walter Bright from comment #5) > > Changed to reflect your last comment. > > No, this is still a regression issue around the struct constructor call. > > https://github.com/D-Programming-Language/dmd/pull/4387 I opened a new performance issue: https://issues.dlang.org/show_bug.cgi?id=14133 --
[Issue 14133] New: change in struct ctor lowering generates excessive init code
https://issues.dlang.org/show_bug.cgi?id=14133 Issue ID: 14133 Summary: change in struct ctor lowering generates excessive init code Product: D Version: D2 Hardware: All OS: All Status: NEW Keywords: performance Severity: normal Priority: P1 Component: DMD Assignee: nob...@puremagic.com Reporter: k.hara...@gmail.com Spin-off issue from: https://issues.dlang.org/show_bug.cgi?id=13952 > The amount of code generated for the constructor is still worrisome. > Especially the part that initializes X86Reg, because it initializes every > field individually, it constructs a temporary on the stack only to end up > loading zero into edx. --
[Issue 13952] [REG2.067a] change in struct ctor lowering triggers codegen bug
https://issues.dlang.org/show_bug.cgi?id=13952 Kenji Hara changed: What|Removed |Added Keywords||pull Hardware|x86_64 |All Summary|change in struct ctor |[REG2.067a] change in |lowering generates |struct ctor lowering |excessive init code |triggers codegen bug OS|Linux |All --- Comment #6 from Kenji Hara --- (In reply to Walter Bright from comment #5) > Changed to reflect your last comment. No, this is still a regression issue around the struct constructor call. https://github.com/D-Programming-Language/dmd/pull/4387 --
[Issue 14132] [ICE] error on arrays
https://issues.dlang.org/show_bug.cgi?id=14132 Misu changed: What|Removed |Added Keywords||ice --
[Issue 14132] New: [ICE] error on arrays
https://issues.dlang.org/show_bug.cgi?id=14132
Issue ID: 14132
Summary: [ICE] error on arrays
Product: D
Version: D2
Hardware: x86_64
OS: Windows
Status: NEW
Severity: minor
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: misugi-p...@live.fr
Hi,
I have an ICE when trying to compile this code :
module main;
import std.stdio;
void main(string[] args)
{
bool[][] components = [[false, false]];
bool[] masks = [true, false];
auto wat = (components[0][] & masks[])[];
}
C:\D\dmd2\windows\bin\dmd.exe -debug -gc "main.d" "Entity.d" "EntityManager.d"
"EventManager.d" "-IC:\D\dmd2\src\druntime\import" "-IC:\D\dmd2\src\phobos"
"-odobj\Debug"
"-ofC:\Users\robertg\Documents\Projets\Decs\Decs\bin\Debug\Decs.exe"
Internal error: e2ir.c 1902
Exit code 1
I don't remember what I was trying to do, but I tried to give you minimal
code.
--
[Issue 14130] [REG2.067a] ICE following error in template parameter default value
https://issues.dlang.org/show_bug.cgi?id=14130 Kenji Hara changed: What|Removed |Added Keywords||pull Summary|REG(2.067) Ice following|[REG2.067a] ICE following |error in template parameter |error in template parameter |default value |default value --- Comment #1 from Kenji Hara --- https://github.com/D-Programming-Language/dmd/pull/4386 --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #13 from Ketmar Dark --- i remember that there was some fixes with arrays of structs and dtors, yes. so this seems to be just a typo in the code — using wrong constant to calculare real start of the array. with mentioned fix it "works for me", and the fix seems to be logical. now we have to summon someone knowledgable to either confirm that and fix mainline code, or to reject it, so we can start searching elsewhere. ;-) --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #12 from Andrej Mitrovic --- I've read somewhere that struct dtors are now called when the struct is allocated on the heap. This might reveal some previously undetected bugs. Just my 2 cents.. --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 --- Comment #11 from Ketmar Dark --- seems that the bug is due to the code in `lifetime.d:finalize_array2()`. for big blocks (those which are bigger or equal to PAGESIZE), it does this: `p += LARGEPAD;`, and LARGEPAD is: LARGEPREFIX = 16, // 16 bytes padding at the front of the array LARGEPAD = LARGEPREFIX + 1, seems that LARGEPAD must be used only in overall block size calculations, but not as real padding (real padding is LARGEPREFIX in this case). yet i'm not an expert in D memory management, so i can't say if i'm really right here. fixing `lifetime.d:finalize_array2()` to use `LARGEPREFIX` instead seems to fix the bug. and hey, why anoyone would use 17-byte PREFIX padding anyway? --
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126 Ketmar Dark changed: What|Removed |Added CC||ket...@ketmar.no-ip.org --- Comment #10 from Ketmar Dark --- i can confirm it for GNU/Linux, x86. all `this` pointers are exactly one byte off. --
[Issue 14131] va_copy is broken on posix X86_64
https://issues.dlang.org/show_bug.cgi?id=14131 yebblies changed: What|Removed |Added Keywords||pull --- Comment #1 from yebblies --- Pull to hack around the real issue using alloca: https://github.com/D-Programming-Language/dmd/pull/4385 https://github.com/D-Programming-Language/druntime/pull/1158 --
[Issue 14131] New: va_copy is broken on posix X86_64
https://issues.dlang.org/show_bug.cgi?id=14131
Issue ID: 14131
Summary: va_copy is broken on posix X86_64
Product: D
Version: D2
Hardware: x86_64
OS: Linux
Status: NEW
Keywords: wrong-code
Severity: major
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: yebbl...@gmail.com
This code fails on posix X86_64 because va_copy doesn't properly copy the
argument pointer, instead aliasing the original.
void copya(int a, string format, ...)
{
va_list ap;
va_start(ap, format);
va_list ap2;
va_copy(ap2, ap);
auto a1 = va_arg!int(ap);
auto a2 = va_arg!int(ap);
auto a3 = va_arg!int(ap);
assert(a1 == 0x);
assert(a2 == 0x);
assert(a3 == 0x);
auto b1 = va_arg!int(ap2);
auto b2 = va_arg!int(ap2);
auto b3 = va_arg!int(ap2);
assert(b1 == 0x);
assert(b2 == 0x);
assert(b3 == 0x);
va_end(ap);
va_end(ap2);
}
void testCopy()
{
copya(0, "", 0x, 0x, 0x);
}
--
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126
--- Comment #9 from sinkuup...@gmail.com ---
Looks like the destructor is called with wrong 'this' pointer.
import core.stdc.stdio;
struct Foo {
private uint _foo = 1;
~this() {
printf("%p\n", &this);
}
}
void main() {
Foo[] foos;
foos.length = 512;
foreach (ref f; foos) printf("%p\n", &f);
printf("--\n");
}
Output:
0x7fa2a6420010
0x7fa2a6420014
0x7fa2a6420018
...
--
...
0x7fa2a6420019
0x7fa2a6420015
0x7fa2a6420011
--
[Issue 14126] GITHEAD - GC seemingly corrupting memory
https://issues.dlang.org/show_bug.cgi?id=14126
sinkuup...@gmail.com changed:
What|Removed |Added
CC||sinkuup...@gmail.com
--- Comment #8 from sinkuup...@gmail.com ---
It seems FooBar class isn't required.
import core.stdc.stdio;
struct Foo {
private uint _foo = 1;
~this() {
printf("%d\n", _foo);
}
}
void main() {
Foo[] foos;
foos.length = 512;
}
This prints "1" with 2.066.1, but prints "16777216" with 2.067a. On my system,
array length must be >= 510 to reproduce the bug.
--
[Issue 14130] New: REG(2.067) Ice following error in template parameter default value
https://issues.dlang.org/show_bug.cgi?id=14130
Issue ID: 14130
Summary: REG(2.067) Ice following error in template parameter
default value
Product: D
Version: D2
Hardware: All
OS: All
Status: NEW
Keywords: ice
Severity: regression
Priority: P1
Component: DMD
Assignee: nob...@puremagic.com
Reporter: yebbl...@gmail.com
F sumKBN(Range, F = Unqual)(Range r, F s = 0.0)
{
}
void main()
{
0.sumKBN;
}
DMD v2.067 DEBUG
testx.d(7): Error: undefined identifier Unqual
assert template.c(2586) fd->type->ty == Tfunction
--
