[Issue 8105] in ref
http://d.puremagic.com/issues/show_bug.cgi?id=8105 --- Comment #1 from github-bugzi...@puremagic.com 2012-06-12 20:10:26 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/687044996a06535210801577e5d68b72edfa3985 fix Issue 8105 - in ref -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106 --- Comment #3 from Manu 2012-06-12 17:24:20 PDT --- (In reply to comment #2) > Can you please verify the behavior you are seeing? Sorry, that should have a typeof(): pragma(msg, typeof(func).stringof); -> void(Colour c = cast(Colour)white) I don't recall it showing the cast that way at work (old GDC differences perhaps), but that's what I'm seeing right now. Either way, that should surely read c = Colour.white instead. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8105] in ref
http://d.puremagic.com/issues/show_bug.cgi?id=8105 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4364] ICE(class.c) compiling a struct def named 'Object' followed by a class definition
http://d.puremagic.com/issues/show_bug.cgi?id=4364 Walter Bright 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 8106] func.stringof with default args
http://d.puremagic.com/issues/show_bug.cgi?id=8106
Walter Bright changed:
What|Removed |Added
CC||bugzi...@digitalmars.com
--- Comment #2 from Walter Bright 2012-06-12
16:46:31 PDT ---
For this program:
===
struct Colour
{
ubyte a,r,g,b;
immutable Colour white = Colour(255,255,255,255);
}
void func(Colour c = Colour.white);
void main()
{
pragma(msg, func.stringof);
}
===
it prints:
func(white)
not:
void func(Colour c = white)
Can you please verify the behavior you are seeing?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 8108] Forward declaration and implementation allowed in same file
http://d.puremagic.com/issues/show_bug.cgi?id=8108 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com Severity|normal |enhancement -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8198] Nested lambda inference doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=8198 Walter Bright 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 4364] ICE(class.c) compiling a struct def named 'Object' followed by a class definition
http://d.puremagic.com/issues/show_bug.cgi?id=4364 --- Comment #4 from github-bugzi...@puremagic.com 2012-06-12 15:58:47 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/fbe7a1c9e107c9eb4bba8f27c87f248b7e6889ae fix Issue 4364 - ICE(class.c) compiling a struct def named 'Object' followed by a class definition Stop looking for 'Object' type. https://github.com/D-Programming-Language/dmd/commit/1c618b0b1336e442767037cf86a103446765 Merge pull request #974 from 9rnsr/fix4364 Issue 4364 - ICE(class.c) compiling a struct def named 'Object' followed by a class definition -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8198] Nested lambda inference doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=8198 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-12 11:43:25 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/f9bf4a373260d2afc47814c904609d3fa39f4167 fix Issue 8198 - Nested lambda inference doesn't work https://github.com/D-Programming-Language/dmd/commit/053ee7208565929297f027b9cff411b986336162 Merge pull request #981 from 9rnsr/fix_funclit Issue 8198 - Nested lambda inference doesn't work -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8232] New: Segmentation fault in rt_finalize_gc()
http://d.puremagic.com/issues/show_bug.cgi?id=8232 Summary: Segmentation fault in rt_finalize_gc() Product: D Version: D2 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: nob...@puremagic.com ReportedBy: marian.povo...@gmail.com --- Comment #0 from Marjan Povolni 2012-06-12 11:01:29 PDT --- Created an attachment (id=1114) Code causing segmentation fault The 42 lines in the attached file cause a segmentation fault, while parsing a larger textual file. For example, I used the following file, but unzipped it first: ftp://ftp.wormbase.org/pub/wormbase/species/m_hapla/gff/m_hapla.current.annotations.gff3.gz Here is what I get in gdb: Program received signal SIGSEGV, Segmentation fault. 0x080a26b0 in rt_finalize_gc () (gdb) where #0 0x080a26b0 in rt_finalize_gc () #1 0x080a1155 in gc.gcx.Gcx.fullcollect() () #2 0x080a0b4e in gc.gcx.Gcx.fullcollectshell() () #3 0x080a04ea in gc.gcx.Gcx.bigAlloc() () #4 0x0809e66e in gc.gcx.GC.mallocNoSync() () #5 0x0809e50f in gc.gcx.GC.malloc() () #6 0x08094e5e in gc_malloc () #7 0x0809638d in _d_newclass () #8 0x080acfb7 in core.runtime.defaultTraceHandler() () #9 0x0809cfc9 in _d_traceContext () #10 0x08095c44 in _d_createTrace () #11 0xb21c in ?? () (gdb) The code uses only the safe subset of D, therefore the worst that should happen is an exception. But here I have a segfault. Me and two others were not able to reduce this code further. Small changes make this segfault go away. For example, it occurs only if the array size in the new statement is 8177 or greater. If it's less, there is no segfault. Replacing "line ~= current_chunk[0..newline_index];" with "line = line ~ current_chunk[0..newline_index];" will also make the segfault go away. The segfault occurs in both 32bit and 64bit builds on Linux, using DMD v2.059. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8229] string literals are not zero-terminated during CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=8229
--- Comment #2 from timon.g...@gmx.ch 2012-06-12 10:55:45 PDT ---
(In reply to comment #1)
> This behaviour is intentional. Pointer operations are strictly checked in
> CTFE.
> It's the same as doing
>
> int n = 0;
> char c = ""[n];
>
> which generates an array bounds error at runtime.
>
I think that would be stretching it too far. It is more like:
auto s = ['\0'];
auto q = s[0..0];
char c = *q.ptr;
Which works fine at runtime and during CTFE.
> Is the terminating null character still in the spec? A long time ago it was in
> there, but now I can only find two references to it in the current spec (in
> 'arrays' and in 'interfacing to C'), and they both relate to printf.
>
> The most detailed is in 'interface to C', which states:
> "string literals, when they are not part of an initializer to a larger data
> structure, have a '\0' character helpfully stored after the end of them."
>
> which is pretty weird. These funky semantics would be difficult to implement
> in
> CTFE,
I guess this is from D1 times, when string literals were static arrays, and
doesn't apply anymore.
> and I doubt they are desirable. Here's an example:
>
> const(char)[] foo(char[] s) { return "abc" ~ s; }
>
> immutable bar = foo("xyz"); // becomes a string literal when it leaves CTFE
>
Well, this is not specified afaics.
> bool baz()
> {
> immutable bar2 = foo("xyz"); // local variable, so isn't a string literal.
>
> return true;
> }
> static assert(baz());
>
> ---> bar is zero-terminated, bar2 is not, even though they had the same
> assignment. When does this magical trailing zero get added?
>
This is exactly the behavior that is observed at runtime. If it is undesirable,
then that is a distinct issue that should be investigated.
It would certainly be desirable to have consistent behavior at compile time and
at runtime, but this is not a top-priority issue.
> I think you could reasonably interpret the spec as meaning that a trailing
> zero
> is added to the end of string literals by the linker, not by the compiler.
> It's
> only in CTFE that you can tell the difference.
In this case, the spec should definitely be fixed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 7585] functions in templates inferred as delegate
http://d.puremagic.com/issues/show_bug.cgi?id=7585 --- Comment #9 from github-bugzi...@puremagic.com 2012-06-12 10:06:25 PDT --- Commits pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/24b83f373e93fc553e42213132adabb992c03405 fix Issue 7585 - functions in templates inferred as delegate https://github.com/D-Programming-Language/dmd/commit/c66af72bd96110c027db69ea560b6dc3f88b3054 Merge pull request #982 from 9rnsr/fix7585 Issue 7585 - functions in templates inferred as delegate -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5082] delegate alias parameters are silently accepted inside structs. limits most of std.algorithm, etc.
http://d.puremagic.com/issues/show_bug.cgi?id=5082 Walter Bright 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 8194] "Function cannot access frame" even though all I requested was the type
http://d.puremagic.com/issues/show_bug.cgi?id=8194 Walter Bright 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 8194] "Function cannot access frame" even though all I requested was the type
http://d.puremagic.com/issues/show_bug.cgi?id=8194 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-12 09:59:43 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/a1c4351fa4e1a7a06c61dfc1575e0608a064dbf0 fix Issue 8194 - "Function cannot access frame" even though all I requested was the type -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 5082] delegate alias parameters are silently accepted inside structs. limits most of std.algorithm, etc.
http://d.puremagic.com/issues/show_bug.cgi?id=5082 --- Comment #2 from github-bugzi...@puremagic.com 2012-06-12 09:59:35 PDT --- Commit pushed to master at https://github.com/D-Programming-Language/dmd https://github.com/D-Programming-Language/dmd/commit/db33a88a267993bf51fb83fd191b816f75a53c41 fix Issue 5082 - delegate alias parameters are silently accepted inside structs. limits most of std.algorithm, etc. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 8229] string literals are not zero-terminated during CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=8229
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #1 from Don 2012-06-12 09:48:41 PDT ---
This behaviour is intentional. Pointer operations are strictly checked in CTFE.
It's the same as doing
int n = 0;
char c = ""[n];
which generates an array bounds error at runtime.
Is the terminating null character still in the spec? A long time ago it was in
there, but now I can only find two references to it in the current spec (in
'arrays' and in 'interfacing to C'), and they both relate to printf.
The most detailed is in 'interface to C', which states:
"string literals, when they are not part of an initializer to a larger data
structure, have a '\0' character helpfully stored after the end of them."
which is pretty weird. These funky semantics would be difficult to implement in
CTFE, and I doubt they are desirable. Here's an example:
const(char)[] foo(char[] s) { return "abc" ~ s; }
immutable bar = foo("xyz"); // becomes a string literal when it leaves CTFE
bool baz()
{
immutable bar2 = foo("xyz"); // local variable, so isn't a string literal.
return true;
}
static assert(baz());
---> bar is zero-terminated, bar2 is not, even though they had the same
assignment. When does this magical trailing zero get added?
I think you could reasonably interpret the spec as meaning that a trailing zero
is added to the end of string literals by the linker, not by the compiler. It's
only in CTFE that you can tell the difference.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
