[Issue 1170] Cannot forward reference a type defined in a MixinStatement
http://d.puremagic.com/issues/show_bug.cgi?id=1170 --- Comment #4 from Rainer Schuetze r.sagita...@gmx.de 2009-09-29 23:51:07 PDT --- The patch only fixes the name lookup, not the forward reference. As described in comment 1, you'll also need the patch from issue 102 to completely fix the original test case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3292] ICE(todt.c) when using a named mixin with an initializer as template alias parameter
http://d.puremagic.com/issues/show_bug.cgi?id=3292 Don clugd...@yahoo.com.au changed: What|Removed |Added Summary|ICE(todt.c) when using a|ICE(todt.c) when using a |named mixin with an |named mixin with an |initializer |initializer as template ||alias parameter --- Comment #2 from Don clugd...@yahoo.com.au 2009-09-29 23:52:44 PDT --- Another variation gives an ICE in optimize.c. Replace void *magic = null; with void* magic = cast(void*)(0); Again, it's because no 'type' is NULL. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3325] ICE(func.c) function literal with post-contract
http://d.puremagic.com/issues/show_bug.cgi?id=3325 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||patch --- Comment #7 from Don clugd...@yahoo.com.au 2009-09-29 23:52:50 PDT --- (In reply to comment #1) This ICE is because it needs to know the return type, before it can create the result variable for the post-condition. Creation of the result variable should probably happen in ReturnStatement::semantic, and the semantic for the post-condition run _after_ the function semantic, instead of before. That wouldn't actually work, because there may be more than one return statement -- the result variable needs to be added at the start of the function. Maybe it's better for now to simply disallow postconditions on functions with type inference return statements, turning it from an ICE into an obscure rejects-valid. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3316] Functions nested in a pure templated function cannot reference its local variables
http://d.puremagic.com/issues/show_bug.cgi?id=3316
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #1 from Don clugd...@yahoo.com.au 2009-09-29 23:56:55 PDT ---
This is happening because the nested template is being marked as pure. This
happens in mtype.c, in TypeFunction::semantic, line 4038:
the template function gets marked as pure/nothrow because it's taken from the
parent scope. This is wrong, because pure/nothrow shouldn't be inherited by
members.
PATCH: In DeclarationExp::semantic(Scope *sc), pure (and nothrow) should not be
passed on to members. Turn it off while running semantic on those functions.
Index: expression.c
===
--- expression.c(revision 196)
+++ expression.c(working copy)
\@@ -4505,8 +4505,12 @@
}
if (!s-isVarDeclaration())
{
+// 'pure nothrow' is not inherited by member declarations
+int scopePureNothrow = sc-stc (STCpure | STCnothrow);
+sc-stc ^= scopePureNothrow;
declaration-semantic(sc);
s-parent = sc-parent;
+sc-stc ^= scopePureNothrow;
}
if (!global.errors)
{
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3351] New: Reference diagrams
http://d.puremagic.com/issues/show_bug.cgi?id=3351 Summary: Reference diagrams Product: D Version: unspecified Platform: Other OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: www.digitalmars.com AssignedTo: nob...@puremagic.com ReportedBy: moi...@hotmail.com --- Comment #0 from assorted moi...@hotmail.com 2009-09-30 00:46:01 PDT --- I kind of miss these kind of diagrams, showing what exactly is going on under the hood. http://bayimg.com/NaeOgaaCC -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3352] New: RangeError in std.conv
http://d.puremagic.com/issues/show_bug.cgi?id=3352 Summary: RangeError in std.conv Product: D Version: 2.032 Platform: x86 OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: dfj1es...@sneakemail.com --- Comment #0 from Sobirari Muhomori dfj1es...@sneakemail.com 2009-09-30 03:58:10 PDT --- --- wtext(int.max); --- core.exception.rangeer...@std.conv(2526): Range violation Unittests in std.conv don't test wstring and big numbers. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3352] RangeError in std.conv
http://d.puremagic.com/issues/show_bug.cgi?id=3352 Andrei Alexandrescu and...@metalanguage.com changed: What|Removed |Added Status|NEW |ASSIGNED CC||and...@metalanguage.com -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3353] New: storage class of a member function is propagated to default arguments
http://d.puremagic.com/issues/show_bug.cgi?id=3353
Summary: storage class of a member function is propagated to
default arguments
Product: D
Version: 2.032
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze r.sagita...@gmx.de 2009-09-30 13:55:03
PDT ---
Compiling the module test.d:
public struct foo
{
public this(real aleft)
{
}
}
class bar
{
final void fun(foo arg = foo(0.)) { }
}
produces:
test.d(11): Error: variable test.bar.__ctmp1 final cannot be applied to
variable
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1012] cannot instantiate template with no or default arguments without !()
http://d.puremagic.com/issues/show_bug.cgi?id=1012 --- Comment #4 from Rainer Schuetze r.sagita...@gmx.de 2009-09-30 14:48:47 PDT --- Created an attachment (id=466) convert TypeIdentifer refering to TemplateDeclaration to TypeInstance I don't expect any additional ambiguities, because the template types are in the same namespace as all other identifers anyway (apart from version and debug identifiers). This patch against 2.032 converts a TypeIdentifier (as created by the parser) into a TypeInstance if name lookup revealed that it is actually a template. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
