[Issue 190] Cannot forward reference typedef/alias in default value for function parameter
http://d.puremagic.com/issues/show_bug.cgi?id=190 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added CC||r.sagita...@gmx.de --- Comment #3 from Rainer Schuetze r.sagita...@gmx.de 2010-07-20 14:07:12 PDT --- The problem of the original test case is the default initializer. It is evaluated when the type of the function is inferred, but the referenced variable has not yet been semantically analyzed. Here's a patch: Index: expression.c === --- expression.c(revision 576) +++ expression.c(working copy) @@ -4350,6 +4350,8 @@ } #endif } +if(type !type-deco) +type = type-semantic(loc, sc); /* Fix for 1161 doesn't work because it causes protection * problems when instantiating imported templates passing private @@ -6046,7 +6048,8 @@ e-type = v-type; } } -return e-deref(); +e = e-deref(); +return e-semantic(sc); } FuncDeclaration *f = s-isFuncDeclaration(); The test case in comment 2 is something different and compiles with DMD 2.047. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4104] No way to get notified about D runtime termination.
http://d.puremagic.com/issues/show_bug.cgi?id=4104 Sean Kelly s...@invisibleduck.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from Sean Kelly s...@invisibleduck.org 2010-07-20 15:09:44 PDT --- Is this something that can be addressed via a shared module dtor, or is that too early/late in the termination process? isHalting seems of limited utility so I tentatively deprecated it, but perhaps it should be replaced by a status field instead? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4360] Allow intrinsics in core.bitop to operate as intrinsics
http://d.puremagic.com/issues/show_bug.cgi?id=4360 --- Comment #2 from Sean Kelly s...@invisibleduck.org 2010-07-20 15:18:59 PDT --- Missed the patch? I don't think it's been applied yet, at least as far as I can tell from looking at the DMD source. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4385] Uncaught exceptions should dump a core
http://d.puremagic.com/issues/show_bug.cgi?id=4385 --- Comment #1 from Leandro Lucarella llu...@gmail.com 2010-07-20 16:32:55 PDT --- I just saw changeset 341 (http://www.dsource.org/projects/druntime/changeset/341), thanks for giving this issue some attention. But unless I'm missing something, this change doesn't help much, because the core will be at the point the call to abort() was made, that (again unless I'm missing something) won't be deep in the call stack, where the throw was done. Having a core dumped where the *throw* was made is what is really valuable, as it let you analyze the dead program in the point where it really died. I don't know how hard would be to achieve this, I just know is possible because the C++ runtime (GCC at least) do it. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3462] Add a clean way to exit a process.
http://d.puremagic.com/issues/show_bug.cgi?id=3462 --- Comment #6 from Leandro Lucarella llu...@gmail.com 2010-07-20 17:33:30 PDT --- I'm not very familiar with the new threading model in D2, I'm mostly a D1 user, so I can't really say. Sorry and thanks to take the time to answer. -- 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 #27 from Leandro Lucarella llu...@gmail.com 2010-07-20 19:33:05
PDT ---
I'm trying to test this patch but I'm having some problems compiling Tango (I'm
using 0.99.9, not trunk). With the patched DMD, I get this error:
dmd: mtype.c:5671: void PointerMap::pointer(size_t): Assertion `offset
m_size' failed.
Compiling the file: tango/util/digest/MerkleDamgard.d
Here is some output from a GDB session:
(gdb) bt
#0 0x2b421bf3c175 in *__GI_raise (sig=value optimized out) at
../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x2b421bf3ef80 in *__GI_abort () at abort.c:92
#2 0x2b421bf352b1 in *__GI___assert_fail (assertion=0x58be62 offset
m_size, file=value optimized out, line=5671, function=0x58bea0 void
PointerMap::pointer(size_t)) at assert.c:81
#3 0x004f5d55 in PointerMap::pointer (this=0x7fff15974fc0, offset=20)
at mtype.c:5671
#4 0x004eaf15 in TypeDArray::fillPointerMap (this=0x11735e0,
pm=0x7fff15974fc0, offset=12) at mtype.c:2241
#5 0x004679d4 in VarDeclaration::fillPointerMap (this=0x1130700,
pm=0x7fff15974fc0, a_offset=0) at declaration.c:1379
#6 0x0040488b in AttribDeclaration::fillPointerMap (this=0x11307c0,
pm=0x7fff15974fc0, offset=0) at attrib.c:289
#7 0x00542327 in ClassDeclaration::toObjFile (this=0x1130150,
multiobj=0) at toobj.c:484
#8 0x00404689 in AttribDeclaration::toObjFile (this=0x113afd0,
multiobj=0) at attrib.c:240
#9 0x004c0da1 in Module::genobjfile (this=0x112bfd0, multiobj=0) at
glue.c:267
#10 0x004e1560 in main (argc=13, argv=0x111f930) at mars.c:1285
(gdb) list
5666 * Actually does nothing if the offset isn't aligned.
5667 */
5668
5669void PointerMap::pointer(size_t offset)
5670{
5671assert(offset m_size);
5672//reject unaligned pointers
5673if (offset % sizeof(size_t))
5674return;
5675size_t bitpos = offset / sizeof(size_t);
(gdb) print offset
$1 = 20
(gdb) print m_size
$2 = 20
(gdb) up
#4 0x004eaf15 in TypeDArray::fillPointerMap (this=0x11735e0,
pm=0x7fff15974fc0, offset=12) at mtype.c:2241
2241pm-pointer(offset + sizeof(size_t));
(gdb) list
2236}
2237
2238void TypeDArray::fillPointerMap(PointerMap *pm, size_t offset)
2239{
2240// like struct Array { size_t length; byte* data; }
2241pm-pointer(offset + sizeof(size_t));
2242}
2243
2244/* TypeAArray
*/
2245
(gdb) print *pm
$3 = {
m_bits = {
Object = {
_vptr.Object = 0x5939d0
},
members of Bits:
bitdim = 3,
allocdim = 1,
data = 0x11e4c70
},
m_size = 20
}
(gdb) print offset
$4 = 12
I don't know enough about DMD internals to debug this myself, so any help will
be very much appreciated.
I'd like to run my test suite to the GC with precise scanning to see how it
goes. I've noticed that false pointers can add a lot of variance in the time a
program can take in Linux, where the addresses returned by mmap() is
randomized, so there are times where the address range returned by mmap() is
much more prone to receive false pointers. See this for the full story:
http://www.llucax.com.ar/blog/blog/post/-7a56a111
Running dil to generate the full Tango documentation can take from 50 to 80
seconds depending on the address range returned by the OS (I suspect because of
false pointers; which I hope to prove trying this patch :)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2544] implicit const casting rules allow violations of const-safety
http://d.puremagic.com/issues/show_bug.cgi?id=2544 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added Version|D1 D2 |2.022 --- Comment #11 from Leandro Lucarella llu...@gmail.com 2010-07-20 19:35:41 PDT --- I'm sorry about the last version change, I accidentally changed it thinking I was editing bug 3463 instead (I hate bugzilla for automatically moving to the next bug report when committing changes). -- 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 #28 from Leandro Lucarella llu...@gmail.com 2010-07-20 19:51:19
PDT ---
Some extra info:
(gdb) up
#5 0x004679d4 in VarDeclaration::fillPointerMap (this=0x1130700,
pm=0x7fff15974fc0, a_offset=0) at declaration.c:1379
1379type-fillPointerMap(pm, offset + a_offset);
(gdb) list
1374
1375void VarDeclaration::fillPointerMap(PointerMap *pm, size_t a_offset)
1376{
1377//printf(VarDeclaration::fillPointerMap() %s, ty = %d, offs=%d\n,
toChars(), type-ty, (int)offset);
1378if (!isDataseg())
1379type-fillPointerMap(pm, offset + a_offset);
1380}
1381
1382/**
1383 * If a variable has an auto destructor call, return call for it.
I have commented out that printf() and this is what I got:
VarDeclaration::fillPointerMap() bytes, ty = 19, offs=8
VarDeclaration::fillPointerMap() buffer, ty = 0, offs=12
dmd: mtype.c:5671: void PointerMap::pointer(size_t): Assertion `offset
m_size' failed.
And this is the piece of D code triggering the assertion:
package class MerkleDamgard : Digest
{
private uintbytes;
private ubyte[] buffer; This one!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
