[Issue 4498] New: cannot get return type of a function returning a nested struct with typeof
http://d.puremagic.com/issues/show_bug.cgi?id=4498
Summary: cannot get return type of a function returning a
nested struct with typeof
Product: D
Version: D2
Platform: Other
OS/Version: Linux
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kamm-removet...@incasoftware.de
--- Comment #0 from Christian Kamm 2010-07-23
23:50:08 PDT ---
auto foo()
{
struct S {}
S s;
return s;
}
static assert(is(typeof(foo(; // fails
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4497] New: inexpressive error message for const object method
http://d.puremagic.com/issues/show_bug.cgi?id=4497
Summary: inexpressive error message for const object method
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: mrmoc...@gmx.de
--- Comment #0 from Trass3r 2010-07-23 18:16:17 PDT ---
class Foo
{
void getX()
{}
}
const Foo f;
void main()
{
f.getX();
}
Error: function constobj.Foo.getX () is not callable using argument types ()
const
This error message could be more expressive to show that getX must be marked as
const to make it work.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
outage (already over)
Sorry for the bugzilla outage a little while ago. The box got way overloaded. Should be all happy now.
[Issue 4496] New: aa.get broken when using get and opIndexAssign in same statement
http://d.puremagic.com/issues/show_bug.cgi?id=4496
Summary: aa.get broken when using get and opIndexAssign in same
statement
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha 2010-07-23 13:55:05 PDT ---
import std.stdio, std.contracts, std.conv;
void main() {
int[string] aa;
aa["foo"] = aa.get("foo", 5);
// This fails because aa["foo"] ends up being 0.
enforce(aa["foo"] == 5, text(aa["foo"]));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4495] New: The -Hd (import file generation directory) option for DMD doesn't work correctly in 2.047.
http://d.puremagic.com/issues/show_bug.cgi?id=4495 Summary: The -Hd (import file generation directory) option for DMD doesn't work correctly in 2.047. Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: jaysis...@yahoo.com --- Comment #0 from jaysis...@yahoo.com 2010-07-23 13:08:05 PDT --- When compiling a library, if more than 1 .d file is specified with directories in the path of the .d files and the -Hd option is used, then DMD 2.047 does not take the directories in the paths in to account when generating the .di files. For example: Directory of files: file1.d dir1/file2.d dir2/file3.d The DMD command line: dmd -lib -oflibfile.a -Hdimport file1.d dir1/file2.d dir2/file3.d Expected results: libfile.a import/file1.di import/dir1/file2.di import/dir2/file3.di Actual results with DMD 2.047: libfile.a import/file1.di import/file2.di import/file3.di Therefore, the compiler cannot find the correct path to the .di file when compiling an application using this library because if "import dir2.file2" were used in the application, the compiler would look for a file in [imports path]/dir2/file2.di, but it would (correctly) not look for that import as [imports path]/file2.di, which is where DMD 2.047 outputs it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
Incorrect behavior of -Hd option
When compiling a library, if more than 1 .d file is specified with directories in the path of the .d files and the -Hd option is used, then DMD 2.047 does not take the directories in the paths in to account when generating the .di files. For example: Directory of files: file1.d dir1/file2.d dir2/file3.d The DMD command line: dmd -lib -oflibfile.a -Hdimport file1.d dir1/file2.d dir2/file3.d Expected results: libfile.a import/file1.di import/dir1/file2.di import/dir2/file3.di Actual results with DMD 2.047: libfile.a import/file1.di import/file2.di import/file3.di Therefore, the compiler cannot find the correct path to the .di file when compiling an application using this library because if "import dir2.file2" were used in the application, the compiler would look for a file in [imports path]/dir2/file2.di, but it would (correctly) not look for that import as [imports path]/file2.di, which is where DMD 2.047 outputs it.
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #44 from Leandro Lucarella 2010-07-23 12:15:44 PDT --- (In reply to comment #43) > You're right, there seem to be some places where the bitmask size is added or > substracted twice. I don't really know; I took that code over from dsimcha's > patch without modification. I was just thankful that I hadn't to write this > code. I fixed the three issues you found. It seems to work, though I'm not > 100% > sure if it's correct now. Thanks! > Regarding moving collectors: > > I think this would be an interesting experiment and worth trying. My patch now > has a second bitmask, where each bit tells whether a word is a moveable > pointer or not. > > Instead of a second bitmap, you could just have a per-memory block flag that > tells whether a memory block is a void[] and/or contains unions with pointers. > (If the flag is set, the GC won't change any pointers inside the block.) You > could maintain that flag as additional bitmap (along NOSCAN etc). This way > storing small bitmaps inline would be simpler. Unions or fixed-size void[] are > probably seldom enough to justify this simplification. gcx.d can choose either > way to implement it using the compiler generated bitmasks. Yes, that can be a nice optimization if void[] and unions are rare. > Before actually implementing a moving GC, one should experiment how many > pinned pointers the stack/manually added ranges/unmovable pointers/datasegment > generate and how they would fragment the heap. Yup! This patch opens that posibility too! Which is great. > Also note that some runtime parts are not ready yet for a moving GC, such as > Object.toHash. Yes, this is just a step in the right direction, not a final solution. Thanks again! A bikeshed suggestion, maybe it would be better to call PointerMap methods this way: isPointerAt() -> mustScanWordAt() isMoveablePointerAt() -> isPointerAt() hasUnmoveablePointers() -> canUpdatePointers() Because the pointers are not "moveable", the memory they point at is the one moveable or not. The pointer, if really pointer, are updateable, and if they are not guaranteed to be pointers, we shouldn't call them that. That's why I think is clearer to call a "may be pointer" a word that should be scanned and a guaranteed pointer (which the GC could update) simply a pointer. By the same means, I'd call pointer_bits and mpointer_bits scan_bits and pointer_bits respectively. BTW, there is already a GC attribute called NO_MOVE, which follows this nomenclature (is supposed to be used for blocks that can't be moved, not for blocks which pointers can't be updated). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 --- Comment #43 from nfx...@gmail.com 2010-07-23 11:39:19 PDT --- You're right, there seem to be some places where the bitmask size is added or substracted twice. I don't really know; I took that code over from dsimcha's patch without modification. I was just thankful that I hadn't to write this code. I fixed the three issues you found. It seems to work, though I'm not 100% sure if it's correct now. Regarding moving collectors: I think this would be an interesting experiment and worth trying. My patch now has a second bitmask, where each bit tells whether a word is a moveable pointer or not. Instead of a second bitmap, you could just have a per-memory block flag that tells whether a memory block is a void[] and/or contains unions with pointers. (If the flag is set, the GC won't change any pointers inside the block.) You could maintain that flag as additional bitmap (along NOSCAN etc). This way storing small bitmaps inline would be simpler. Unions or fixed-size void[] are probably seldom enough to justify this simplification. gcx.d can choose either way to implement it using the compiler generated bitmasks. Before actually implementing a moving GC, one should experiment how many pinned pointers the stack/manually added ranges/unmovable pointers/datasegment generate and how they would fragment the heap. Also note that some runtime parts are not ready yet for a moving GC, such as Object.toHash. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 nfx...@gmail.com changed: What|Removed |Added Attachment #693 is|0 |1 obsolete|| --- Comment #42 from nfx...@gmail.com 2010-07-23 11:35:23 PDT --- Created an attachment (id=696) D1 - patch for Tango's runtime to enable precise GC scanning - fix bugs mentioned by comments 38-40 - add a bitmask for moveable pointers -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3463] Integrate Precise Heap Scanning Into the GC
http://d.puremagic.com/issues/show_bug.cgi?id=3463 nfx...@gmail.com changed: What|Removed |Added Attachment #692 is|0 |1 obsolete|| --- Comment #41 from nfx...@gmail.com 2010-07-23 11:33:38 PDT --- Created an attachment (id=695) D1 - patch for dmd for creating pointer bitmasks -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4494] New: [ICE] Array literal filled with results of void function
http://d.puremagic.com/issues/show_bug.cgi?id=4494
Summary: [ICE] Array literal filled with results of void
function
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 2010-07-23 09:59:30 PDT ---
void foo() {}
void main() {
[foo];
}
Dmd 2.047 prints:
Internal error: ..\ztc\cod1.c 2650
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3326] Regression(2.010): $ in delegate literal causes Access Violation
http://d.puremagic.com/issues/show_bug.cgi?id=3326 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au Version|2.032 |D2 Summary|$ in delegate literal |Regression(2.010): $ in |causes Access Violation |delegate literal causes ||Access Violation Severity|normal |regression --- Comment #1 from Don 2010-07-23 00:05:49 PDT --- This worked in 2.000 and all versions of D1, Failed with access violation in 2.012. Bumping up to regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
