[Issue 4085] New: Steps toward a static foreach
http://d.puremagic.com/issues/show_bug.cgi?id=4085
Summary: Steps toward a static foreach
Product: D
Version: future
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-04-12 18:30:59 PDT ---
A "static foreach" can be useful to statically unroll loops (both on a small
numerical range, or for example on items of an array/matrix known at compile
time, this can significantly improve the performance of some code), to define
many switch cases in a compact way, to reduce code duplication using string
mixins, and so on. It can be useful both inside and outside function bodies.
Currently the foreach on tuples is static, but the new D programmer can ignore
this, and a quick inspection of D code doesn't tell if a foreach is static or
runtime. Generally in D code it's important to always be able to visually tell
apart static statements (like static if, static assert) from their runtime
variants.
At the moment it's possible to use a limited form of static foreach on a
numeric range, using a helper template like (similar Range can be defined with
one and three input arguments):
template Range(int start, int stop) {
static if (stop <= start)
alias Tuple!() Range;
else
alias Tuple!(Range!(start, stop-1), stop-1) Range;
}
But Range generates many templates, works only inside functions, and visually
the code that uses Range!() is not visually distinct from the runtime foreach.
Andrei has commented:
> static foreach was part of the plan until recently, but Walter
> encountered severe implementation difficulties so we had to abandon it.
> I agree that it's odd that the same statement iterates at compile-time
> or run-time depending on the iterated type.
I'd like Walter to explain why it's hard to implement, maybe some other
programmer can find a way to implement it.
Even if a static foreach can't be fully implemented, there are other
intermediate solutions. Even a partially implemented static foreach is an
improvement over the current situation. There are various levels of
implementation of static foreach, more and more complete, each one of them is
better than the last one:
1) Just require the prefix keyword "static" before "foreach" when the foreach
is done on a tuple. This doesn't change the semantics of the current D
programs, but helps who will read the D code to visually tell apart the static
case from the runtime case. I think this is not too much hard to implement.
2) The compiler can translate (lower) code like "static foreach (i; 10 .. 20)"
into something like that "static foreach (i; Range!(10, 20))", using a Range
template defined automatically (this static foreach on a range can be used only
inside functions).
3) The same as point (2), but the compiler can avoid instantiating all those
templates. This can reduce memory used during compilation and speed up the
compilation a little.
4) The same as (3) but it can work on arrays too known at compile time too. The
compiler can convert arrays known at compile time into tuples, and then iterate
on a numerical range as long as the array, and pick items from the tuple usign
an index. (This is already doable now, with a recursive template that converts
an array known at compile time into a tuple).
5) Like (4) but the compiler can optimize better, avoiding the conversion from
the array known at compile time into a tuple (as the precedent levels, this
static foreach can be used only inside functions).
6) This is the full static foreach, that can be used outside the body of any
function too.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1245] static foreach shouldn't define new scope and introduce new variables
http://d.puremagic.com/issues/show_bug.cgi?id=1245 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED CC||bearophile_h...@eml.cc Resolution||FIXED --- Comment #7 from bearophile_h...@eml.cc 2010-04-12 17:52:10 PDT --- This is now fixed in DMD 1.058 and 2.043. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3971] Syntax & semantics for array assigns
http://d.puremagic.com/issues/show_bug.cgi?id=3971
--- Comment #1 from bearophile_h...@eml.cc 2010-04-12 17:41:46 PDT ---
But be careful, in this code Tri c[] is seen as Tri[] c, and it doesn't
compile:
alias double[3] Tri;
void main() {
Tri a = [1, 2, 3];
Tri b = [10, 20, 30];
Tri c[] = a1[] - b1[]; // ERR
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4084] Ignored missing main() closing bracket
http://d.puremagic.com/issues/show_bug.cgi?id=4084 --- Comment #1 from Ellery Newcomer 2010-04-12 14:50:29 PDT --- Created an attachment (id=610) enforce closing brace after opening brace in statement one line fix (yawn) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2437] ICE(tocsym.c, !needThis()) - default struct argument
http://d.puremagic.com/issues/show_bug.cgi?id=2437
--- Comment #5 from Don 2010-04-12 13:51:13 PDT ---
See also the closely related bug 2935.
I can patch this (against svn 433) with these two changes (and the DMD test
suite still passes), which basically just remove the checks, in the case where
a CTFE variable is used. I'm not certain these patches are correct, though.
-- PATCH --
tocsym.c, line 170:
Symbol *VarDeclaration::toSymbol()
{
//printf("VarDeclaration::toSymbol(%s)\n", toChars());
//if (needThis()) *(char*)0=0;
+if (!isCTFE())
assert(!needThis());
and secondly, in e2ir.c, SymbolExp::toElem() line 664:
//printf("SymbolExp::toElem('%s') %p\n", toChars(), this);
//printf("\tparent = '%s'\n", var->parent ? var->parent->toChars() :
"null");
-if (op == TOKvar && var->needThis())
+if (op == TOKvar && var->needThis() && !v->isCTFE())
{
error("need 'this' to access member %s", toChars());
return el_long(TYint, 0);
}
-
A totally different (and probably better) alternative would be to fix it in
expression.c, around line 6770, when the temporary variable is created. If
(!sc->func), it's being created in global scope, and should be neither in
STCfield nor STCextern storage class. But I'm not sure how this should be done.
// First look for constructor
if (ad->ctor && arguments && arguments->dim)
{
// Create variable that will get constructed
Identifier *idtmp = Lexer::uniqueId("__ctmp");
VarDeclaration *tmp = new VarDeclaration(loc, t1, idtmp, NULL);
tmp->storage_class |= STCctfe;
+if (!sc->func) {
+ // it's being created in global scope. Do something!!
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2935] ICE(out.c) using struct with constructor as function default argument
http://d.puremagic.com/issues/show_bug.cgi?id=2935
Don changed:
What|Removed |Added
Keywords||patch
--- Comment #6 from Don 2010-04-12 13:01:45 PDT ---
PATCH:
I think it's enough to change tocsym.c, VarDeclaration::toSymbol(),
around line 201. If it's a CTFE variable, it's shouldn't be marked as an
extern.
t->Tcount++;
-if (isDataseg())
+if (isDataseg() && !isCTFE())
{
if (isThreadlocal())
{ /* Thread local storage
*/
TYPE *ts = t;
ts->Tcount++; // make sure a different t is allocated
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4084] New: Ignored missing main() closing bracket
http://d.puremagic.com/issues/show_bug.cgi?id=4084
Summary: Ignored missing main() closing bracket
Product: D
Version: future
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: accepts-invalid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-04-12 12:02:43 PDT ---
This program compiles and runs with no errors with dmd 2.043 (note the missing
closing bracket):
void main() {
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 622] There should be a warning for unininitalized class reference
http://d.puremagic.com/issues/show_bug.cgi?id=622 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #3 from bearophile_h...@eml.cc 2010-04-12 12:00:02 PDT --- This bug is half-fixed: the compiler is now able to catch this bug at compile-time, but only if the code is compiled with -O. I think the compiler has to catch this bug when not optimized mode is used too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4077] Bugs caused by bitwise operator precedence
http://d.puremagic.com/issues/show_bug.cgi?id=4077 --- Comment #7 from Adam D. Ruppe 2010-04-12 06:42:57 PDT --- (In reply to comment #4) > My experience shows that it's easy to forget bugs, because they are seen as > something negative, so I suggest you to write them down :-) Aye, probably true. I think another reason why too is I usually put the parenthesis around it all the time - probably one of those things I started doing a long time ago after being hit by the bug, then over the years did out of habit without remembering specifically why I started in the first place. Requiring parenthesis or changing the precidence would be nice in any case. There's no cost I can see (outside of implementing it in the compiler, of course), and even a small benefit is better than none. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4077] Bugs caused by bitwise operator precedence
http://d.puremagic.com/issues/show_bug.cgi?id=4077 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #6 from Steven Schveighoffer 2010-04-12 06:09:47 PDT --- (In reply to comment #1) > Care to quantify 'frequent'? Just because something can cause a bug doesn't > make it a disaster. I can't recall ever making a bit wise precedence error > myself. Of course, that too isn't proof of anything. I run into this all the time. It makes me absolutely paranoid about bitops to where I sometimes write things like: if((a | b)) or a = (b | c); Before I realize the extra parens don't do much :) If you write routines that parse protocols or use bitfield flags, you will run into this bug. I always wondered why bitwise operators were lower in precedence than comparison, but you just learn to accept it (and judiciously use parentheses around such things). If D could make strides to help solve this problem, I think it would be great. Probably not earth shattering, but just another feather in the cap. When someone writes something like: if(a | b == c) I'd say it's always an error. Not even almost always, but always. If D could flag this as such, it would be a good thing. I strongly feel, however, that bitwise ops should simply have a higher precedent than comparison, since the current behavior is always an error. You will not find any C code that looks like this on purpose. I don't see any reason to keep the current interpretation regardless. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4059] Incorrect C++ name mangling
http://d.puremagic.com/issues/show_bug.cgi?id=4059 Koroskin Denis <2kor...@gmail.com> changed: What|Removed |Added CC||2kor...@gmail.com Severity|normal |blocker --- Comment #3 from Koroskin Denis <2kor...@gmail.com> 2010-04-12 06:02:09 PDT --- Rising the severity as it is indeed a blocker -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4082] New: nothrow main() can throw
http://d.puremagic.com/issues/show_bug.cgi?id=4082
Summary: nothrow main() can throw
Product: D
Version: future
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-04-12 04:26:37 PDT ---
This program compiles with dmd 2.043, and the main() throws, even if it's a
nothrow function:
struct Foo {
~this() { throw new Exception(""); }
}
nothrow void main() {
Foo f;
goto NEXT;
NEXT:;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4083] New: Exception-related code from nothrow destructor
http://d.puremagic.com/issues/show_bug.cgi?id=4083
Summary: Exception-related code from nothrow destructor
Product: D
Version: future
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: performance
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-04-12 04:29:17 PDT ---
This can be related to bug 4082.
This program works correctly with dmd 2.043, but the resulting asm contains
code for the management of exceptions even if the destructor of the struct Foo
is nothrow (I am not sure if this situation can be improved):
struct Foo {
nothrow ~this() {}
}
void main() {
Foo f;
goto NEXT;
NEXT:;
}
__Dmain
L0: pushEBP
mov EBP,ESP
mov EDX,FS:__except_list
push0h
pushoffset __Dmain[061h]
pushEDX
mov FS:__except_list,ESP
sub ESP,8
pushEAX
pushEBX
pushESI
pushEDI
mov dword ptr -4[EBP],0
mov dword ptr -4[EBP],0h
lea ECX,-0Ch[EBP]
push0h
pushECX
pushoffset FLAT:_DATA
callnear ptr __d_local_unwind2
add ESP,0Ch
pushoffset __Dmain[04Eh]
mov dword ptr -4[EBP],0h
ret
mov ECX,-0Ch[EBP]
xor EAX,EAX
mov FS:__except_list,ECX
pop EDI
pop ESI
pop EBX
mov ESP,EBP
pop EBP
ret
mov EAX,offset FLAT:_DATA
jmp near ptr __d_framehandler
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
Re: Missing trailing } still compiles under DMD1.057
Please report bugs here:
http://d.puremagic.com/issues/
This newsgroup is just a feed from Bugzilla.
-Lars
Sam Hu wrote:
Given below code:
module uniword;
import std.c.stdio;
import std.c.windows.windows;
import std.stdio;
import *;
void main()
{
testFoo;
}
struct Foo
{
int a;
static Foo opCall(int a)
{
Foo s;
s.a=a;
return s;
}
}
void testFoo()
{
Foo x=Foo(10);
writefln("%d\n",x.a);
readln;
