[Issue 3387] gdb: symbols in the backtrace are not demangled
http://d.puremagic.com/issues/show_bug.cgi?id=3387 Leandro Lucarella changed: What|Removed |Added Version|1.047 |1.051 Severity|regression |normal --- Comment #2 from Leandro Lucarella 2009-10-19 19:07:58 PDT --- It doesn't look like a regression after all, it seems to depend on whatever -g or -gc is used. With -g I get the properly demangled names, but with -gc I don't. The problem is, -g is broken with GDB, so I can't use -g. It would be a problem to have -gc producing the necessary debug info to get properly demangled names? Sorry for the noise. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3381] [tdpl] Incorrect assessment of overriding in triangular-shaped hierarchy
http://d.puremagic.com/issues/show_bug.cgi?id=3381 --- Comment #5 from Andrei Alexandrescu 2009-10-19 12:55:57 PDT --- (In reply to comment #4) > I wonder you (Andrei) don't search for existing bugs instead of blindly > creating new ones =( > > If you want to mark all TDPL bugs by prefixing [tldp] to the subject, you can > edit the old bug's title. > > I'm saying this because I saw several bugs which were duplicates of old ones. I'll try to look harder. My problem is that I never know what keywords to look for. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3381] [tdpl] Incorrect assessment of overriding in triangular-shaped hierarchy
http://d.puremagic.com/issues/show_bug.cgi?id=3381 Leandro Lucarella changed: What|Removed |Added CC||llu...@gmail.com --- Comment #4 from Leandro Lucarella 2009-10-19 12:46:00 PDT --- I wonder you (Andrei) don't search for existing bugs instead of blindly creating new ones =( If you want to mark all TDPL bugs by prefixing [tldp] to the subject, you can edit the old bug's title. I'm saying this because I saw several bugs which were duplicates of old ones. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3023] override keyword fail if iface has several super interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=3023 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #1 from Don 2009-10-19 12:15:37 PDT --- My patch for bug 3381 fixes this. (reported later, but TDPL bugs get priority). *** This issue has been marked as a duplicate of issue 3381 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3381] [tdpl] Incorrect assessment of overriding in triangular-shaped hierarchy
http://d.puremagic.com/issues/show_bug.cgi?id=3381 Don changed: What|Removed |Added CC||larsi...@igesund.net --- Comment #3 from Don 2009-10-19 12:15:37 PDT --- *** Issue 3023 has been marked as a duplicate of this issue. *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3381] [tdpl] Incorrect assessment of overriding in triangular-shaped hierarchy
http://d.puremagic.com/issues/show_bug.cgi?id=3381
Don changed:
What|Removed |Added
Keywords||patch
CC||clugd...@yahoo.com.au
--- Comment #2 from Don 2009-10-19 12:13:55 PDT ---
Ha! Compiler bugs are not usually this silly.
Applies to D1 as well. This also fixes bug 3023. I suspect it probably fixes
some other bugs too -- I'm amazed multiple inheritance has worked at all.
class.c, line 1198.
// Skip if b has already appeared
for (int k = 0; k < i; k++)
{
-if (b == interfaces[i])
+if (b == interfaces[k])
goto Lcontinue;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2364] ftell return type is long in C, that is 64-bit on x86-64
http://d.puremagic.com/issues/show_bug.cgi?id=2364 Brad Roberts changed: What|Removed |Added CC||bra...@puremagic.com Resolution|INVALID |FIXED --- Comment #6 from Brad Roberts 2009-10-19 09:20:26 PDT --- Changing to resolved-fixed. In druntime, where this stuff lives now, it's defined as a c_long: c_long ftell(FILE* stream); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3421] Inline assembler problems accessing static variables
http://d.puremagic.com/issues/show_bug.cgi?id=3421 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don 2009-10-19 08:37:32 PDT --- It's a change. statics are now thread-local by default. You need to mark as __gshared if you want the D1 behaviour. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3421] New: Inline assembler problems accessing static variables
http://d.puremagic.com/issues/show_bug.cgi?id=3421
Summary: Inline assembler problems accessing static variables
Product: D
Version: 2.035
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: grahamc00...@yahoo.co.uk
--- Comment #0 from Graham 2009-10-19 08:03:19 PDT
---
This code works in DMD v1.047 and fails in DMD v2.035
import std.stdio;
static int value1;
void main() {
value1 = 2;
asm {
movEAX,1;
mov[value1],EAX;
}
writefln("value1 %d", value1);
}
The code generated in each case is:
Compiled under DMD v 1.047:
> u __Dmain l39
TEST03!__Dmain+0x0:
0x00402010 55 push ebp
0x00402011 8bec mov ebp,esp
0x00402013 c705801445000200
mov dword ptr [_D6test036value1i
(00451480)],0002
0x0040201d b80100 mov eax,0001
0x00402022 a380144500 mov dword ptr [_D6test036value1i
(00451480)],eax
0x00402027 ff3580144500 push dword ptr [_D6test036value1i
(00451480)]
0x0040202d ff3594b04400 push dword ptr [_TMP0+0004 (0044b094)]
0x00402033 ff3590b04400 push dword ptr [_TMP0 (0044b090)]
0x00402039 b8f0b04400 mov eax,0044b0f0
0x0040203e 50 push eax
0x0040203f e83017 call _D3std5stdio8writeflnFYv (00403774)
0x00402044 83c410 add esp,10
0x00402047 5d pop ebp
0x00402048 c3 retn
>
Compiled under DMD v 2.0035:
> u __Dmain l43
TEST03!__Dmain+0x0:
0x00402010 55 push ebp
0x00402011 8bec mov ebp,esp
0x00402013 53 push ebx
0x00402014 64a12c00 mov eax,dword ptr fs:[002c]
0x0040201a 8b08 mov ecx,dword ptr [eax]
0x0040201c c78104000200
mov dword ptr [ecx+0004],0002
0x00402026 b80100 mov eax,0001
0x0040202b a30400 mov dword ptr [0004],eax
0x00402030 ff3594904200 push dword ptr [_TMP0+0004 (00429094)]
0x00402036 ff3590904200 push dword ptr [_TMP0 (00429090)]
0x0040203c 648b152c00 mov edx,dword ptr fs:[002c]
0x00402043 8b1a mov ebx,dword ptr [edx]
0x00402045 8b830400 mov eax,dword ptr [ebx+0004]
0x0040204b e80400 call
_D3std5stdio19__T8writeflnTAyaTiZ8writeflnFAyaiZv (00402054)
0x00402050 5b pop ebx
0x00402051 5d pop ebp
0x00402052 c3 retn
>
The "D" code accesses 'value1' as dword ptr [ecx+0004] and the inline
assember as dword ptr [0004]
Is this a change in the language runtime specification for how module static
variables are accessed or it this a bug ?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3420] New: Impossible to specify -J path for subdirectories
http://d.puremagic.com/issues/show_bug.cgi?id=3420
Summary: Impossible to specify -J path for subdirectories
Product: D
Version: 1.042
Platform: All
OS/Version: Windows
Status: NEW
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: thecybersha...@gmail.com
--- Comment #0 from Vladimir 2009-10-19 07:55:10 PDT
---
const data = import("dir/data.txt");
Specifying -J. for DMD 1.041 is sufficient to allow this to compile.
I couldn't find an option for DMD 1.042 and newer which would allow this to
compile.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3416] Non-compilable template instantiation in is(typeof()) fails compilation
http://d.puremagic.com/issues/show_bug.cgi?id=3416 --- Comment #7 from Don 2009-10-19 07:19:54 PDT --- (In reply to comment #6) > Ok, but there is no other way to determine if some syntactically correct code > is also correct semantically. And without that, D's metaprogramming system is > of little use. I think you're overstating the problem. Certainly it's an annoyance. But in my experience it is quite easy to work around it. > Anyway, I'm not sure whether semantically incorrect code should produce a > valid > type, which void is. Should it? Dunno. To avoid that, it would have to instantiate the body of every template, recursively. > And the current compiler seems to treat __traits(compiles, X) and > is(typeof(X)) > identically... THAT is definitely a bug. > I think this bug should remain open until is(typeof(X)) is fixed or a > different/better mechanism is introduced. And it is definitely a blocker. A comment: 30% of the blockers in Bugzilla are from you. None of them have any votes, not even from you. You might want to change that. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3416] Non-compilable template instantiation in is(typeof()) fails compilation
http://d.puremagic.com/issues/show_bug.cgi?id=3416 --- Comment #6 from Max Samukha 2009-10-19 06:24:50 PDT --- Ok, but there is no other way to determine if some syntactically correct code is also correct semantically. And without that, D's metaprogramming system is of little use. Anyway, I'm not sure whether semantically incorrect code should produce a valid type, which void is. Should it? And the current compiler seems to treat __traits(compiles, X) and is(typeof(X)) identically... I think this bug should remain open until is(typeof(X)) is fixed or a different/better mechanism is introduced. And it is definitely a blocker. Thanks -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3088] std.xml.check() fails on xml comments
http://d.puremagic.com/issues/show_bug.cgi?id=3088 --- Comment #1 from Bernard Helyer 2009-10-19 05:46:26 PDT --- Changed this to all, because it happens over here (x86) too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3416] Non-compilable template instantiation in is(typeof()) fails compilation
http://d.puremagic.com/issues/show_bug.cgi?id=3416 Don changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #5 from Don 2009-10-19 05:29:45 PDT --- I don't think this is a bug. You're assuming that is(typeof(X)) is a test for whether X compiles. But it isn't. is(typeof(X)) only checks if the X has a semantically valid type. And in this case it does, because it's declared as void. There's a larger issue, in that is(typeof(X)) is ugly, and it's very common to want to see if something compiles. In fact it's arguably the ugliest thing in the language right now. But it's not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3416] Non-compilable template instantiation in is(typeof()) fails compilation
http://d.puremagic.com/issues/show_bug.cgi?id=3416
--- Comment #4 from Max Samukha 2009-10-19 05:09:11
PDT ---
Interestingly, if 'foo' is instantiated in 'static assert', is incorrectly
evaluated to true.
template bar(T)
{
private void baz()
{
T a = null;
}
}
template foo(T)
{
enum foo = is(typeof(bar!T));
}
static assert(!foo!int);
Error: static assert (!true) is false
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1647] linux.mak in phobos' sources tries to compile missing file std/slist.d
http://d.puremagic.com/issues/show_bug.cgi?id=1647 Don changed: What|Removed |Added Status|REOPENED|RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #3 from Don 2009-10-19 04:15:46 PDT --- Fixed in early 2008. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3388] [tdpl] contracts should allow throw expressions
http://d.puremagic.com/issues/show_bug.cgi?id=3388 Don changed: What|Removed |Added Keywords||patch CC||clugd...@yahoo.com.au --- Comment #1 from Don 2009-10-19 04:13:46 PDT --- This seems to work if you just comment out the error (statement.c 4299) (BTW a nothrow function can have a contract which calls functions that may throw. Not sure if that's OK or not, probably not but I think it's not urgent). -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3390] [tdpl] out(result) contract should not be able to rebind result
http://d.puremagic.com/issues/show_bug.cgi?id=3390
Don changed:
What|Removed |Added
Keywords||patch
CC||clugd...@yahoo.com.au
--- Comment #1 from Don 2009-10-19 04:13:13 PDT ---
PATCH: Why not just make 'result' const?
// func.c, line 1030.
v = new VarDeclaration(loc, type->nextOf(), outId, NULL);
v->noauto = 1;
#if DMDV2
+ v->storage_class |= STCconst;
if (f->isref)
{
v->storage_class |= STCref | STCforeach;
}
#endif
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3282] The overload and override issue of const/immutable member functions
http://d.puremagic.com/issues/show_bug.cgi?id=3282 --- Comment #1 from Haruki Shigemori 2009-10-19 03:22:09 PDT --- This problem occurs when "const" is "shared". -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2364] ftell return type is long in C, that is 64-bit on x86-64
http://d.puremagic.com/issues/show_bug.cgi?id=2364 Tomas Lindquist Olsen changed: What|Removed |Added CC||to...@famolsen.dk --- Comment #5 from Tomas Lindquist Olsen 2009-10-19 03:20:56 PDT --- Even with the misunderstanding of C long being 32 or 64 bit, translating a C long to a D int is still wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3409] stdio.File.seek() doesn't work for files >2GB
http://d.puremagic.com/issues/show_bug.cgi?id=3409 Sobirari Muhomori changed: What|Removed |Added Severity|regression |major --- Comment #8 from Sobirari Muhomori 2009-10-19 02:25:26 PDT --- No, headers are correct, see http://www.dsource.org/projects/druntime/browser/trunk/import/core/stdc/stdio.d http://www.kernel.org/doc/man-pages/online/pages/man3/fseek.3.html -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3409] stdio.File.seek() doesn't work for files >2GB
http://d.puremagic.com/issues/show_bug.cgi?id=3409 Sobirari Muhomori changed: What|Removed |Added Severity|major |regression --- Comment #7 from Sobirari Muhomori 2009-10-19 02:20:19 PDT --- Strange, in 2.020 it was intfseek(FILE* stream, c_long offset, int whence); so this is regression. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2364] ftell return type is long in C, that is 64-bit on x86-64
http://d.puremagic.com/issues/show_bug.cgi?id=2364 Sobirari Muhomori changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3409] stdio.File.seek() doesn't work for files >2GB
http://d.puremagic.com/issues/show_bug.cgi?id=3409 --- Comment #6 from Sobirari Muhomori 2009-10-19 02:13:29 PDT --- (In reply to comment #4) > Could be wrong, but I think the way druntime defines these functions is > because > that's the way they're defined in the C std lib API. Yes, but that's *C* API, so the type should be c_long. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3418] New: link error with cast(ulong)(ulong*real)
http://d.puremagic.com/issues/show_bug.cgi?id=3418 Summary: link error with cast(ulong)(ulong*real) Product: D Version: 2.035 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: rin...@gmail.com --- Comment #0 from ZY Zhou 2009-10-19 02:13:05 PDT --- test case: ulong a = 1; a = cast(ulong)(a * 2.0L); ERROR message: OPTLINK (R) for Win32 Release 8.00.1 Copyright (C) Digital Mars 1989-2004 All rights reserved. C:\d\dmd2\windows\bin\..\lib\SNN.lib(u64_ldbl) Offset FFE74H Record Type 0091 Error 1: Previous Definition Different : ___LDBLULLNG -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3409] stdio.File.seek() doesn't work for files >2GB
http://d.puremagic.com/issues/show_bug.cgi?id=3409 --- Comment #5 from Sobirari Muhomori 2009-10-19 02:08:08 PDT --- > I don't know why under Windows c_long is actually 32 bit. because msvc compiler is LLP64. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3416] Non-compilable template instantiation in is(typeof()) fails compilation
http://d.puremagic.com/issues/show_bug.cgi?id=3416
--- Comment #3 from Max Samukha 2009-10-19 02:00:52
PDT ---
That is just a minimal test case. We should be able to check if a template can
be instantiated with given template arguments. Here is a better test case:
template bar(T)
{
void baz()
{
T a;
a = null; // this may or may not be valid code, depending on T
}
}
enum foo = is(typeof(bar!int)); // this should evaluate to false
test.d(22): Error: cannot implicitly convert expression (null) of type void* to
int
May be a regression.
Note that the following compiles as expected:
template bar(T)
{
T a = null; // this may or may not be valid code, depending on T
}
static assert(!is(typeof(bar!int)));
static assert(is(typeof(bar!(void*;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2551] std.format on invariant values : error and segmentation fault
http://d.puremagic.com/issues/show_bug.cgi?id=2551 Don changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||FIXED --- Comment #3 from Don 2009-10-19 01:19:49 PDT --- This was fixed between 2.026 and 2.030. I believe the segfault was fixed in 2.027. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
