[Issue 3276] New: Mutual recursion broken in type templates
http://d.puremagic.com/issues/show_bug.cgi?id=3276 Summary: Mutual recursion broken in type templates Product: D Version: 2.032 Platform: x86 OS/Version: Windows Status: NEW Severity: critical Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bart...@relisoft.com Created an attachment (id=442) --> (http://d.puremagic.com/issues/attachment.cgi?id=442) bug example Recursion in templates works, but mutual recursion doesn’t. I’m attaching this example—it can’t be reduced much further. Each part of it works separately, but once they start recursing into each other, I get the error: small.d(3): Error: alias small.F!(void*).StripPtr recursive alias declaration -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 314] Static, renamed, and selective imports are always public
http://d.puremagic.com/issues/show_bug.cgi?id=314 Matti Niemenmaa changed: What|Removed |Added CC||2kor...@gmail.com --- Comment #11 from Matti Niemenmaa 2009-08-31 11:56:41 PDT --- *** Issue 3275 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 3275] Private selective imports are visible in another module
http://d.puremagic.com/issues/show_bug.cgi?id=3275 Matti Niemenmaa changed: What|Removed |Added Status|NEW |RESOLVED CC||matti.niemenmaa+dbugzi...@i ||ki.fi Resolution||DUPLICATE --- Comment #1 from Matti Niemenmaa 2009-08-31 11:56:41 PDT --- *** This issue has been marked as a duplicate of issue 314 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3204] Document global properties
http://d.puremagic.com/issues/show_bug.cgi?id=3204 --- Comment #2 from Michiel Helvensteijn 2009-08-31 11:19:57 PDT --- Is there any particular reason? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3275] New: Private selective imports are visible in another module
http://d.puremagic.com/issues/show_bug.cgi?id=3275
Summary: Private selective imports are visible in another
module
Product: D
Version: 2.031
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: 2kor...@gmail.com
(A duplicate, probably, but I couldn't find exact same issue)
Here is a test case:
module A;
import std.stdio : writeln;
module B;
import A;
void main()
{
writeln("this line shouldn't compile");
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2773] ICE(go.c) array assignment through a pointer, only with -O.
http://d.puremagic.com/issues/show_bug.cgi?id=2773 Don changed: What|Removed |Added Severity|regression |critical --- Comment #6 from Don 2009-08-31 08:23:36 PDT --- This isn't a regression. It failed on DMD1.022 as well, which was released in mid-2007, almost 2 years before this bug report. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3173] ICE(mtype.c) on wrong code (double to long to int conversion)
http://d.puremagic.com/issues/show_bug.cgi?id=3173 Don changed: What|Removed |Added Severity|normal |regression --- Comment #1 from Don 2009-08-31 08:16:52 PDT --- This is a regression. It worked in 2.022. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2861] Forward reference of .stringof in a template gives wrong value
http://d.puremagic.com/issues/show_bug.cgi?id=2861
Don changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||FIXED
--- Comment #1 from Don 2009-08-31 07:57:51 PDT ---
Fixed DMD2.030 and 1.045.
This works now.
Test case was wrong, though, should have been:
--
template Templ(T) {
const char[] x = (Type).stringof;
alias T Type;
}
void main() {
static assert(Templ!(int).x =="int");
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3183] Spec of align attribute needs work
http://d.puremagic.com/issues/show_bug.cgi?id=3183
--- Comment #2 from Stewart Gordon 2009-08-31 04:57:28 PDT ---
(In reply to comment #1)
> 2. There's always a companion C compiler, as D relies on the existence of the
> C
> runtime library.
So a prerequisite for writing a D compiler from scratch is to write a C
compiler first? Still, that doesn't answer my question beyond the first 7
words.
> 3. It's the way the companion C compiler aligns.
Still, that this may be absolute or relative depending on the companion C
compiler ought to be mentioned in the D spec at least to crack down on the user
confusion of which I have been a victim.
> 4. Unions members are all at offset 0. Unions are aligned according to the
> alignment of their largest field.
You mean aligned in a containing struct, or aligned absolutely _if_ the
implementation interprets alignment as absolute? Neither seems to be happening
in my test (1.046):
--
align(1) struct Qwert {
byte b1;
align(1) struct {
byte b2;
union {
align (4) struct { int i; }
}
}
}
pragma(msg, "Qwert.alignof == " ~ Qwert.alignof.stringof);
pragma(msg, "Qwert.b1.alignof == " ~ Qwert.b1.alignof.stringof);
pragma(msg, "Qwert.b2.alignof == " ~ Qwert.b2.alignof.stringof);
pragma(msg, "Qwert.i.alignof == " ~ Qwert.i.alignof.stringof);
pragma(msg, "Qwert.b1.offsetof == " ~ Qwert.b1.offsetof.stringof);
pragma(msg, "Qwert.b2.offsetof == " ~ Qwert.b2.offsetof.stringof);
pragma(msg, "Qwert.i.offsetof == " ~ Qwert.i.offsetof.stringof);
--
Qwert.alignof == 1u
Qwert.b1.alignof == 1u
Qwert.b2.alignof == 1u
Qwert.i.alignof == 4u
Qwert.b1.offsetof == 0u
Qwert.b2.offsetof == 1u
Qwert.i.offsetof == 2u
--
But to both 4 and 5, I said "should", i.e. I was pondering over what's
desirable and whether the spec ought to be changed, not what the current spec
or behaviour is.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3152] Broken link for Glee D
http://d.puremagic.com/issues/show_bug.cgi?id=3152 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright 2009-08-31 03:21:57 PDT --- Fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3151] Broken link for akide
http://d.puremagic.com/issues/show_bug.cgi?id=3151 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright 2009-08-31 03:23:43 PDT --- Fixed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2560] ICE(cod4.c) on invoking method that takes ref const struct parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2560 --- Comment #9 from HOSOKAWA Kenchi 2009-08-31 03:03:17 PDT --- (In reply to comment #8) > The reason why it doesn't fail for float and double is that they have sizes of > 4=int.sizeof and 8=long.sizeof, and get inlined at an earlier stage in the > backend. So structs with size 1,2,4, and 8 are immune from the ICE. Real is > size 10, so it ICEs. It's nothing to do with floating point at all. I am reassured by your good analysis. thank you. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3204] Document global properties
http://d.puremagic.com/issues/show_bug.cgi?id=3204 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright 2009-08-31 02:56:29 PDT --- For D2, such "global properties" will no longer be allowed. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2560] ICE(cod4.c) on invoking method that takes ref const struct parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2560 --- Comment #8 from Don 2009-08-31 02:52:15 PDT --- (In reply to comment #7) > (In reply to comment #5) > > *** Issue 2847 has been marked as a duplicate of this issue. *** > > However I agree these issues are duplicate of this, don't forget specialty of > real. > In Issue 2847, only real causes ICE, besides float and double do not. > Both const(struct) and const(real) may be behind assertion failure at cod4.c > 35#. > Bugs about real have harmful effects on numeric computing, so that this point > must be important for you. The reason why it doesn't fail for float and double is that they have sizes of 4=int.sizeof and 8=long.sizeof, and get inlined at an earlier stage in the backend. So structs with size 1,2,4, and 8 are immune from the ICE. Real is size 10, so it ICEs. It's nothing to do with floating point at all. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2560] ICE(cod4.c) on invoking method that takes ref const struct parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2560 --- Comment #7 from HOSOKAWA Kenchi 2009-08-31 02:41:10 PDT --- (In reply to comment #5) > *** Issue 2847 has been marked as a duplicate of this issue. *** However I agree these issues are duplicate of this, don't forget specialty of real. In Issue 2847, only real causes ICE, besides float and double do not. Both const(struct) and const(real) may be behind assertion failure at cod4.c 35#. Bugs about real have harmful effects on numeric computing, so that this point must be important for you. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3183] Spec of align attribute needs work
http://d.puremagic.com/issues/show_bug.cgi?id=3183 Walter Bright changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright 2009-08-31 02:44:07 PDT --- 1. C ABI compatibility. 2. There's always a companion C compiler, as D relies on the existence of the C runtime library. 3. It's the way the companion C compiler aligns. 4. Unions members are all at offset 0. Unions are aligned according to the alignment of their largest field. 5. It is ignored for non-struct fields. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2560] ICE(cod4.c) on invoking method that takes ref const struct parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2560 Don changed: What|Removed |Added CC||mikolalyse...@gmail.com --- Comment #6 from Don 2009-08-31 02:25:02 PDT --- *** Issue 2969 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 2969] ICE(cod4.c) using const function parameter inside delegate
http://d.puremagic.com/issues/show_bug.cgi?id=2969 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #4 from Don 2009-08-31 02:25:02 PDT --- This is another duplicate of 2560. Worked in 2.022. *** This issue has been marked as a duplicate of issue 2560 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2560] ICE(cod4.c) on invoking method that takes ref const struct parameter
http://d.puremagic.com/issues/show_bug.cgi?id=2560 Don changed: What|Removed |Added CC||hs...@inter7.jp --- Comment #5 from Don 2009-08-31 02:22:44 PDT --- *** Issue 2847 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 2847] ICE(cod4.c) return const(struct) with real member
http://d.puremagic.com/issues/show_bug.cgi?id=2847 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #3 from Don 2009-08-31 02:22:44 PDT --- This is exactly the same as 2665, which is itself the same as 2560. *** This issue has been marked as a duplicate of issue 2560 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2665] ICE(cod4.c) on certain const struct function return types
http://d.puremagic.com/issues/show_bug.cgi?id=2665 --- Comment #5 from Don 2009-08-31 02:18:24 PDT --- Like 2560, this is a regression between 2.022 and 2.023. It's clearly the same bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2665] ICE(cod4.c) on certain const struct function return types
http://d.puremagic.com/issues/show_bug.cgi?id=2665 Don changed: What|Removed |Added Severity|major |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2479] sformat is broken
http://d.puremagic.com/issues/show_bug.cgi?id=2479
Don changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
--- Comment #4 from Don 2009-08-31 01:59:58 PDT ---
Even further reduced, removing all imports. My patch to bug 814 does not fix
this.
--
alias void* va_list;
T va_arg(T)(inout va_list _argptr) {
T arg = *cast(T*)_argptr;
_argptr = _argptr + ((T.sizeof + int.sizeof - 1) & ~(int.sizeof - 1));
return arg;
}
void doFormat(void delegate(dchar) myputc, TypeInfo[] args, va_list
argptr){
string fmt = va_arg!(string)(argptr);
assert(!(fmt is null)); // fires when it shouldn't.
}
char[] sformat(char[] s, ...){
void putc(dchar c) { s[0] = cast(char)c; }
doFormat(&putc, _arguments, _argptr);
return s[0 .. 1];
}
void main(){
char[32] tmp;
sformat(tmp, "%s", "hi");
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
