[Issue 3695] New: __EOF__ token not documented
http://d.puremagic.com/issues/show_bug.cgi?id=3695 Summary: __EOF__ token not documented Product: D Version: future Platform: Other OS/Version: Other Status: NEW Severity: normal Priority: P2 Component: www.digitalmars.com AssignedTo: nob...@puremagic.com ReportedBy: michel.nol...@gmail.com --- Comment #0 from Michel Nolard michel.nol...@gmail.com 2010-01-11 03:39:30 PST --- In D 1.x - D 2.x migration guide and in lex.html, the new token __EOF__ introduced in the D 2 is not documented. I think it should be explained in the Special Tokens section. Thanks. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3524] ICE(e2ir.c): using alias parameter after scope closure error
http://d.puremagic.com/issues/show_bug.cgi?id=3524
Don clugd...@yahoo.com.au changed:
What|Removed |Added
CC||clugd...@yahoo.com.au
Summary|Internal error: e2ir.c |ICE(e2ir.c): using alias
|725, after scoped error|parameter after scope
|and processing inrevelant |closure error
|file. |
--- Comment #3 from Don clugd...@yahoo.com.au 2010-01-11 06:58:54 PST ---
Reduced test case shows that this is some form of memory corruption.
--
class A {}
struct F(alias g) {
void e() {
assert(g);
}
}
void bzium(A a) {
scope A b;
F!(b) c;
F!(a) d;
}
file2.d(10): Error: variable file2.bzium.b has scoped destruction, cannot build
closure
Internal error: e2ir.c 739
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3557] Pure function cannot call struct constructor
http://d.puremagic.com/issues/show_bug.cgi?id=3557
--- Comment #2 from Tomasz Sowiński tomeks...@gmail.com 2010-01-11 13:33:40
PST ---
(In reply to comment #1)
It shouldn't compile, since the constructor isn't marked as pure. But if you
mark the constructor as pure:
pure {
this (float f) {
this.f = f;
}
}
you get:
bug.d(14): Error: cannot modify const/immutable/inout expression this.f
So we definitely have a problem.
Yes, I had a feeling compiler should let me have pure ctors..
What about the problem I mentioned at the bottom (if A is a class):
class A {
float f;
this (float f) {// NOT pure
this.f = f;
}
static pure A stworz(float f) {
return new A(f);
}
}
This compiles. Should it?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3557] Pure function cannot call struct constructor
http://d.puremagic.com/issues/show_bug.cgi?id=3557
--- Comment #3 from Tomasz Sowiński tomeks...@gmail.com 2010-01-11 13:40:33
PST ---
(In reply to comment #2)
This compiles. Should it?
I'm now confident it shouldn't:
string global;
class A {
float f;
this (float f) {// NOT pure
this.f = f;
global = BUGABUGA!;
}
static pure A stworz(float f) {
return new A(f);
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3696] New: SuperStack
http://d.puremagic.com/issues/show_bug.cgi?id=3696
Summary: SuperStack
Product: D
Version: 2.036
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: chadj...@gmail.com
--- Comment #0 from Chad Joan chadj...@gmail.com 2010-01-11 17:32:03 PST ---
http://www.digitalmars.com/pnews/read.php?server=news.digitalmars.comgroup=digitalmars.Dartnum=79746
Quoted from Andrei:
This entire discussion gets me thinking - could an alternate stack be a
good (or even better) solution? Consider a global per-thread
superstack - a growable region that allocates memory in large chunks
and makes sub-chunks accessible in a strictly LIFO manner. The
primitives of the superstack are as follows:
void* SuperStack.allocate(size_t bytes);
void SuperStack.free(size_t bytes);
size_t SuperStack.slack();
The SuperStack's management is a singly-linked list of large blocks. The
slack function returns how many bytes are left over in the current
chunk. If you request more than slack bytes, a new chunk is allocated
etc. A SuperStack can grow indefinitely (and is susceptible to leaks).
Some convenience functions complete the picture:
T[] SuperStack.array(T)(size_t objects);
enum Uninitialized { yeahIKnow }
T[] SuperStack.array(T)(size_t objects, Uninitialized);
Freeing chunks should not be done immediately in order to avoid
pathological behavior when a function repeatedly allocates and frees a
chunk just to fulfill some small data needs.
With the SuperStack in place, code could look like this:
void foo(in size_t s)
{
auto a = SuperStack.array(int)(s, Uninitialized.yeahIKnow);
scope(exit) SuperStack.free(s);
... play with a ...
}
Is there interest for such a thing?
Andrei
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3681] ICE(go.c): when function takes too long to optimize, only with -O.
http://d.puremagic.com/issues/show_bug.cgi?id=3681 Don clugd...@yahoo.com.au changed: What|Removed |Added Summary|ICE(go.c): Multiple |ICE(go.c): when function |assignments inside a|takes too long to optimize, |function, only with -O. |only with -O. --- Comment #3 from Don clugd...@yahoo.com.au 2010-01-11 21:10:35 PST --- The problem is simply that the optimiser needs too much time. The optimiser loops for a maximum of 200 times, but to optimize this example requires 290 loops. On the line it's faulting on: -assert(++iter 200); +assert(++iter 290); However, there'll always be _some_ example where this happens. So a different approach is required. Maybe after 200 check that the number of elements is still decreasing on each pass through the loop; if it is, then just silently exit the loop without ICEing. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3671] x^^3 gives wrong result when x is a floating-point literal
http://d.puremagic.com/issues/show_bug.cgi?id=3671 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-01-11 22:01:23 PST --- Changeset 332 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3675] Regression: Struct literals cannot be initialized with another struct literal
http://d.puremagic.com/issues/show_bug.cgi?id=3675 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-01-11 22:03:45 PST --- Changeset 332 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3535] struct constructors don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=3535 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-01-11 22:02:24 PST --- Changeset 332 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3556] version(CTFE)
http://d.puremagic.com/issues/show_bug.cgi?id=3556 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #2 from Walter Bright bugzi...@digitalmars.com 2010-01-11 22:05:10 PST --- Changeset 332 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3556] version(CTFE)
http://d.puremagic.com/issues/show_bug.cgi?id=3556 --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-01-11 22:06:43 PST --- The reason to prefer if(__ctfe) over version(CTFE) is that both code paths need to be compiled properly, as a function could be executed both at compile and runtime. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3697] New: StructTemplateDeclaration and others missing constraint in rule
http://d.puremagic.com/issues/show_bug.cgi?id=3697 Summary: StructTemplateDeclaration and others missing constraint in rule Product: D Version: 2.038 Platform: All URL: http://digitalmars.com/d/2.0/template.html#UnionTempla teDeclaration OS/Version: All Status: NEW Keywords: spec Severity: normal Priority: P2 Component: www.digitalmars.com AssignedTo: nob...@puremagic.com ReportedBy: jlqu...@optonline.net --- Comment #0 from Jerry Quinn jlqu...@optonline.net 2010-01-11 22:20:21 PST --- The grammar defines StructTemplateDeclaration: struct Identifier ( TemplateParameterList ) StructBody However, in this form, optional template Constraint is missing. I think the grammar should be: StructTemplateDeclaration: struct Identifier ( TemplateParameterList ) Constraints_opt StructBody and the compiler (2.038) agrees. UnionTemplateDeclaration, InterfaceTemplateDeclaration, and ClassTemplateDeclaration should be similarly updated. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3698] New: InterfaceDeclaration rule needs BaseInterfaceList
http://d.puremagic.com/issues/show_bug.cgi?id=3698 Summary: InterfaceDeclaration rule needs BaseInterfaceList Product: D Version: 2.038 Platform: All URL: http://digitalmars.com/d/2.0/interface.html OS/Version: All Status: NEW Severity: normal Priority: P2 Component: www.digitalmars.com AssignedTo: nob...@puremagic.com ReportedBy: jlqu...@optonline.net --- Comment #0 from Jerry Quinn jlqu...@optonline.net 2010-01-11 22:29:33 PST --- The grammar currently defines InterfaceDeclaration: interface Identifier InterfaceBody InterfaceTemplateDeclaration But this doesn't handle interfaces deriving from other interfaces. The following should work: InterfaceDeclaration: interface Identifier InterfaceBody interface Identifier BaseInterfaceList InterfaceBody InterfaceTemplateDeclaration -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2101] CTFE: Please may I use mutable arrays at compile time?
http://d.puremagic.com/issues/show_bug.cgi?id=2101 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2010-01-11 22:58:37 PST --- Changeset 333. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
