[Issue 4771] New: fail_compilation/fail274.d hits a halt in iasm.c
http://d.puremagic.com/issues/show_bug.cgi?id=4771 Summary: fail_compilation/fail274.d hits a halt in iasm.c Product: D Version: D2 Platform: All OS/Version: All Status: NEW Keywords: ice-on-invalid-code Severity: regression Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: bra...@puremagic.com --- Comment #0 from Brad Roberts 2010-08-30 23:52:18 PDT --- ../src/dmd -Ifail_compilation -odtest_results/fail_compilation -oftest_results/fail_compilation/fail274 -c fail_compilation/fail274.d fail_compilation/fail274.d(2): ] expected instead of ';' Program received signal SIGSEGV, Segmentation fault. 0x08128b17 in halt () at mars.c:230 230 *(char*)0=0; (gdb) bt #0 0x08128b17 in halt () at mars.c:230 #1 0x0811571e in asmerr (errnum=16) at iasm.c:1858 #2 0x0811316c in asm_chktok (toknum=TOKrbracket, errnum=16) at iasm.c:541 #3 0x08118b99 in asm_br_exp () at iasm.c:3840 #4 0x08118898 in asm_mul_exp () at iasm.c:3748 #5 0x081187c3 in asm_add_exp () at iasm.c:3709 #6 0x081186ab in asm_shift_exp () at iasm.c:3681 #7 0x0811857b in asm_rel_exp () at iasm.c:3630 #8 0x08118440 in asm_equal_exp () at iasm.c:3587 #9 0x0811839c in asm_and_exp () at iasm.c:3564 #10 0x081182f8 in asm_xor_exp () at iasm.c:3541 #11 0x08118254 in asm_inc_or_exp () at iasm.c:3518 #12 0x08118198 in asm_log_and_exp () at iasm.c:3495 #13 0x081180dc in asm_log_or_exp () at iasm.c:3473 #14 0x0811807c in asm_cond_exp () at iasm.c:3453 #15 0x081199d4 in AsmStatement::semantic (this=0x820e6f8, sc=0x82430e8) at iasm.c:4478 #16 0x08165818 in CompoundStatement::semantic (this=0x820e740, sc=0x82430e8) at statement.c:481 #17 0x080f82a2 in FuncDeclaration::semantic3 (this=0x820e590, sc=0x8243058) at func.c:1215 #18 0x0812d6b2 in Module::semantic3 (this=0x820e068) at module.c:859 #19 0x0812ab72 in main (argc=11, argv=0x82044d0) at mars.c:1193 A regression hunt shows that this was caused by r605 which did affect iasm.c in big ways (despite the fairly innocent submit comment) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4750] fail_compilation/fail225.d causes dmd to segv
http://d.puremagic.com/issues/show_bug.cgi?id=4750
--- Comment #3 from Brad Roberts 2010-08-30 23:29:58 PDT
---
ok, tested on linux with r652:
$ gdb --args ../src/dmd -Ifail_compilation -odtest_results/fail_compilation
-oftest_results/fail_compilation/fail225 -c fail_compilation/fail225.d
fail_compilation/fail225.d(8): Error: cannot implicitly convert expression (1)
of type int to char*
fail_compilation/fail225.d(8): Error: too many initializers for Struct
Program received signal SIGSEGV, Segmentation fault.
0x080b322c in Type::isImmutable (this=0x0) at mtype.h:255
255 int isImmutable() { return mod & MODimmutable; }
(gdb) up
#1 0x0812f10b in Type::invariantOf (this=0x0) at mtype.c:381
381 if (isImmutable())
(gdb)
#2 0x08053c16 in StructLiteralExp::implicitConvTo (this=0x823e390,
t=0x8242f78) at cast.c:433
433 te = te->invariantOf();
(gdb) print te
$1 = (Type *) 0x0
(gdb) print t->mod
$2 = 4 '\004'
(gdb) print *e
$3 = {
= {
_vptr.Object = 0x81c5ee8
},
members of Expression:
loc = {
filename = 0x820e188 "fail_compilation/fail225.d",
linnum = 8
},
op = TOKaddress,
type = 0x0,
size = 28 '\034',
parens = 0 '\000'
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4770] structs don't correctly copy when alias this is used
http://d.puremagic.com/issues/show_bug.cgi?id=4770 David Simcha changed: What|Removed |Added Status|NEW |RESOLVED CC||dsim...@yahoo.com Resolution||DUPLICATE --- Comment #1 from David Simcha 2010-08-30 15:16:14 PDT --- Dup of Bug 2943. *** This issue has been marked as a duplicate of issue 2943 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2943] Struct copying in presence of alias member this only copies alias this member
http://d.puremagic.com/issues/show_bug.cgi?id=2943 David Simcha changed: What|Removed |Added CC||kieron_br...@hotmail.com --- Comment #2 from David Simcha 2010-08-30 15:16:14 PDT --- *** Issue 4770 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 4753] fail_compilation/fail116.d sends dmd into a loop, exhausting memory
http://d.puremagic.com/issues/show_bug.cgi?id=4753
Rainer Schuetze changed:
What|Removed |Added
CC||r.sagita...@gmx.de
--- Comment #2 from Rainer Schuetze 2010-08-30 15:15:59
PDT ---
TypeTypeof should have a recursion check similar to TypeFunction and
TypeTypedef. The test case compiles with the following patch, without reverting
r634.
Index: mtype.c
===
--- mtype.c(revision 638)
+++ mtype.c(working copy)
@@ -5866,6 +5866,7 @@
TypeTypeof::TypeTypeof(Loc loc, Expression *exp)
: TypeQualified(Ttypeof, loc)
{
+inuse = 0;
this->exp = exp;
}
@@ -5909,6 +5910,13 @@
//printf("TypeTypeof::semantic() %p\n", this);
//static int nest; if (++nest == 50) *(char*)0=0;
+if (inuse)
+{
+inuse = 2;
+error(loc, "circular typeof definition");
+return Type::terror;
+}
+inuse++;
#if 0
/* Special case for typeof(this) and typeof(super) since both
@@ -6010,9 +6018,11 @@
goto Lerr;
}
}
+inuse--;
return t;
Lerr:
+inuse--;
return tvoid; // should this be Type::terror?
}
Index: mtype.h
===
--- mtype.h(revision 638)
+++ mtype.h(working copy)
@@ -659,6 +659,7 @@
struct TypeTypeof : TypeQualified
{
Expression *exp;
+int inuse;
TypeTypeof(Loc loc, Expression *exp);
Type *syntaxCopy();
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4770] New: structs don't correctly copy when alias this is used
http://d.puremagic.com/issues/show_bug.cgi?id=4770
Summary: structs don't correctly copy when alias this is used
Product: D
Version: D2
Platform: x86
OS/Version: Windows
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: kieron_br...@hotmail.com
--- Comment #0 from Kieron Brown 2010-08-30 15:12:05
PDT ---
if alias this is used on a member value (whether simple, or another struct)
copying an instantiated struct no longer results in all struct members
being copied (only the aliased value is copied).
The version is Version D 2.048 (version text copied from changelog)
The problem is best illustrated by a minimal example:
- self contained d sample starts -
import std.stdio, std.math;
void main()
{
auto p = Test(0.5, 0.5);
assert(0.5 == p.a); // ok
assert(0.5 == p.b); // ok
Test q;
//q = Test(0.5, 0.5);
//
// the above line can substitute
// the one below and the same
// problem occurs
q = p;
if (isNaN(q.b))
printf("problem replicated\n");
assert(0.5 == q.a); // ok
assert(0.5 == q.b); // this fails
}
struct Test
{
double a;
double b;
alias a this;
}
- end of file -
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4750] fail_compilation/fail225.d causes dmd to segv
http://d.puremagic.com/issues/show_bug.cgi?id=4750 --- Comment #2 from Brad Roberts 2010-08-30 15:07:13 PDT --- I'll sync up tonight and re-verify on linux. If it segv's still, I'll dig into what's up. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 190] Cannot forward reference typedef/alias in default value for function parameter
http://d.puremagic.com/issues/show_bug.cgi?id=190 --- Comment #6 from Walter Bright 2010-08-30 14:01:53 PDT --- reversion: http://www.dsource.org/projects/dmd/changeset/652 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4750] fail_compilation/fail225.d causes dmd to segv
http://d.puremagic.com/issues/show_bug.cgi?id=4750 --- Comment #1 from Don 2010-08-30 14:01:38 PDT --- I cannot reproduce this (on Windows). I tried 2.048, and svn 646, svn 647, svn 648, svn 651. In every case, I get: bad.d(18): Error: cannot implicitly convert expression (1) of type int to char* bad.d(18): Error: too many initializers for Struct bad.d(18): Error: variable bad.main.iStruct is not a static and cannot have stat ic initializer -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4173] Regression(2.037) Explicitly instantiated templates still try to do IFTI in some cases
http://d.puremagic.com/issues/show_bug.cgi?id=4173 --- Comment #2 from Don 2010-08-30 13:52:14 PDT --- This bug was triggered by svn commit 273, which was related to opDispatch. The immediate change was in CallExp::semantic(). Previously, it attempted full instantiation, and if that failed, it tried partial explicit instantiation. After this change, it calls needsTypeInference(). It does partial instantiation if true, otherwise does full instantiation. In this test case, there is one template which requires partial explicit instantantion, and one which does not. So, in 2.036 and earlier, the full instantiation succeeded, before it even considered the two-argument template. Seems as though the code for explicit instantiation is slightly more capable at the moment, than the partial instantiation code. Bug 4430 is probably another instance of the same bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4769] New: Unary atomics
http://d.puremagic.com/issues/show_bug.cgi?id=4769 Summary: Unary atomics Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: enhancement Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: dsim...@yahoo.com --- Comment #0 from David Simcha 2010-08-30 13:28:28 PDT --- core.atomic should provide a way to do perform unary atomic operations on variables to the greatest extent practical. The obvious candidates are: atomicOp!"++"(var); atomicOp!"--"(var); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3493] Segfault(cast.c) Forward reference with type inference, D1 only.
http://d.puremagic.com/issues/show_bug.cgi?id=3493 Walter Bright changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #4 from Walter Bright 2010-08-30 13:26:04 PDT --- Undoing the patch for 190 also breaks this. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4752] fail_compilation/fail345.d asserts in expression.c
http://d.puremagic.com/issues/show_bug.cgi?id=4752 Walter Bright changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||FIXED --- Comment #1 from Walter Bright 2010-08-30 11:41:39 PDT --- http://www.dsource.org/projects/dmd/changeset/651 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4279] AAs change key type
http://d.puremagic.com/issues/show_bug.cgi?id=4279 --- Comment #4 from Steven Schveighoffer 2010-08-30 06:57:47 PDT --- Oh, I didn't notice that. I was looking at bearophile's code. But my point is the same -- converting to const does not guarantee anything. In reality, the only place where you are affected is during iteration, as everywhere else, the key is an input. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4279] AAs change key type
http://d.puremagic.com/issues/show_bug.cgi?id=4279
--- Comment #3 from Andrej Mitrovic 2010-08-30
06:47:23 PDT ---
(In reply to comment #2)
> I think changing the key type to const during iteration is a useless gesture,
> and just serves as an annoyance rather than a guarantee.
>
> See bug 4410 that I reported later but for a different reason.
In this case it doesn't change the key type during iteration, it changes it in
the declaration:
import std.stdio: writeln;
void main()
{
int[char[]] data = [cast(char[])"foo" : 1];
writeln(typeid(data));
}
Prints: int[const(char)[]]
Unless I got it wrong here. :)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4258] "auto ref" doesn't work in one or more cases
http://d.puremagic.com/issues/show_bug.cgi?id=4258
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2010-08-30
06:42:08 PDT ---
I get different errors with 2.048:
bug4258.d(7): Error: 'result' is not a scalar, it is a Vec
bug4258.d(7): Error: 'result' is not of arithmetic type, it is a Vec
bug4258.d(7): Error: 'other' is not of arithmetic type, it is a Vec
bug4258.d(12): Error: template instance bug4258.Vec.opBinary!("+") error
instantiating
bug4258.d(12): Error: 'v' is not a scalar, it is a Vec
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4664] Lambdas default arguments problems
http://d.puremagic.com/issues/show_bug.cgi?id=4664
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #4 from Andrej Mitrovic 2010-08-30
06:35:48 PDT ---
As a quick hack while this isn't fixed you can use this:
auto lam1 = function (int x=5){ writeln(x); };
auto lam2 = delegate (int x=10){ writeln(x); };
But this will only work with 2 lambdas at most, and it isn't very nice. :)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4279] AAs change key type
http://d.puremagic.com/issues/show_bug.cgi?id=4279 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer 2010-08-30 06:18:44 PDT --- I think changing the key type to const during iteration is a useless gesture, and just serves as an annoyance rather than a guarantee. See bug 4410 that I reported later but for a different reason. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3856] const arguments/instance attributes in conditions/invariants
http://d.puremagic.com/issues/show_bug.cgi?id=3856
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #2 from Andrej Mitrovic 2010-08-30
06:10:35 PDT ---
(In reply to comment #0)
> Currently preconditions and postconditions (D contract based programming) can
> modify input arguments, this prints [0, 2]:
>
> import std.stdio: writeln;
>
> void foo(int[] arr)
> out { arr[0] = 0; }
> body {}
>
> void main() {
> auto a = [1, 2];
> foo(a);
> writeln(a);
> }
>
> But I think it's better if arguments are seen as const inside preconditions
> and
> postconditions. Because modifying them alters too much the program behaviour
> between release and not release builds.
>
Yes. As stated in TDPL, changing the state of the application inside an in/out
contract is *illegal*. An application must run with the same behavior and
results whether or not it executes it's contracts (debug vs release mode).
I'm not sure about invariants. Although it would be best if they didn't modify
the state of 'this', they are still allowed to call private methods and in turn
those methods might change the state of the application.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4261] Bad textual printing of enums
http://d.puremagic.com/issues/show_bug.cgi?id=4261
--- Comment #3 from Andrej Mitrovic 2010-08-30
05:47:34 PDT ---
I'm not sure I understand what you're saying. An enum in D is a list of
symbolic values of any type (except classes).
For example:
module enums;
import std.stdio;
struct Color
{
ubyte r, g, b;
}
enum { red = Color(255, 0, 0), green = Color(0, 255, 0), blue = Color(0, 0,
255) }
void foo(Color c)
{
writefln("%s %s %s", c.r, c.g, c.b);
}
void main()
{
foo(blue);
}
enums are also used in CTFE, e.g.:
enum float value = someFunc(); // CTFE
Having to use a cast everywhere for an enum would break a lot of code.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4516] Regression(2.040): forward declaration of enum not supported
http://d.puremagic.com/issues/show_bug.cgi?id=4516 Stewart Gordon changed: What|Removed |Added Version|D1 |D2 --- Comment #7 from Stewart Gordon 2010-08-30 04:44:46 PDT --- But you left this one filed as a D1 bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4261] Bad textual printing of enums
http://d.puremagic.com/issues/show_bug.cgi?id=4261 --- Comment #2 from bearophile_h...@eml.cc 2010-08-30 04:37:55 PDT --- Enums aren't numbers, they are symbols that the language/CPU often represents with numbers. See also bug 3999 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 190] Cannot forward reference typedef/alias in default value for function parameter
http://d.puremagic.com/issues/show_bug.cgi?id=190 Brad Roberts changed: What|Removed |Added Status|RESOLVED|REOPENED CC||bra...@puremagic.com Resolution|FIXED | --- Comment #5 from Brad Roberts 2010-08-30 00:41:06 PDT --- Reopening due to a regression it causes. See bug 4753 for the details. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4753] fail_compilation/fail116.d sends dmd into a loop, exhausting memory
http://d.puremagic.com/issues/show_bug.cgi?id=4753 Brad Roberts changed: What|Removed |Added Severity|normal |regression --- Comment #1 from Brad Roberts 2010-08-30 00:39:15 PDT --- Flagging as a regression. r634 introduced it: This block of the diff is where dmd goes recursive: @@ -4215,6 +4215,9 @@ Expression *VarExp::semantic(Scope *sc) #endif } +if (type && !type->deco) +type = type->semantic(loc, sc); + /* Fix for 1161 doesn't work because it causes protection * problems when instantiating imported templates passing private * variables as alias template parameters. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4516] Regression(2.040): forward declaration of enum not supported
http://d.puremagic.com/issues/show_bug.cgi?id=4516 Don changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Don 2010-08-29 23:59:47 PDT --- I have moved the D1 version of this bug into the newly created bug 4768. Both symptoms and solution are different for D1. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4768] New: Regression(1.056): wrong code with forward declaration of enum
http://d.puremagic.com/issues/show_bug.cgi?id=4768
Summary: Regression(1.056): wrong code with forward declaration
of enum
Product: D
Version: D1
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: regression
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don 2010-08-29 23:57:56 PDT ---
This is the D1 version of bug 4516.
Rejected as 'forward reference error' up to D1.053.
Worked correctly in 1.054 and 1.055. Wrong code in 1.056 and later.
Works if the definition of B is moved above A.
struct A { B b; }
enum B { Z = 2 }
void main()
{
A x;
assert(x.b == 2);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4280] std.typecons.Tuple problem with one field
http://d.puremagic.com/issues/show_bug.cgi?id=4280 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from bearophile_h...@eml.cc 2010-08-29 23:31:16 PDT --- Thank you. I close this, bug is fixed in 2.048. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4416] Function with ref argument breaks struct method const attribute
http://d.puremagic.com/issues/show_bug.cgi?id=4416 --- Comment #2 from bearophile_h...@eml.cc 2010-08-29 23:26:49 PDT --- This is a normal bug, no need to raise its priority. There are far more urgent bugs to fix. I have recently shown in the D newsgroup a list of my bug reports that need higher priority. What needs higher priority are the non-additive changes that are not just bugs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4261] Bad textual printing of enums
http://d.puremagic.com/issues/show_bug.cgi?id=4261
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2010-08-29
21:16:37 PDT ---
When you need to get the name of the enumerated value, you have to use the 'to'
template function from std.conv, as described in TDPL. Your example then
becomes:
import std.conv : to;
import std.stdio: writeln;
void main()
{
enum Foo { Zero, One }
Foo f = Foo.One;
writeln(to!string(f));
}
Prints: One
It wouldn't make much sense for an enum to behave differently in different
contexts (e.g. comparing it in an if statement vs. using it with a writeln).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4707] auto ref for foreach loops
http://d.puremagic.com/issues/show_bug.cgi?id=4707 --- Comment #3 from David Simcha 2010-08-29 21:33:04 PDT --- Another use case for this is if you are iterating over something that may be expensive to copy. In these cases, doing foreach(elem; stuff) is inefficient because it produces an unnecessary copy, but foreach(ref elem; stuff) isn't generic enough because it won't work on ranges w/o lvalue elements. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4279] AAs change key type
http://d.puremagic.com/issues/show_bug.cgi?id=4279
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2010-08-29
21:07:55 PDT ---
As of 2.048, and according to my tests, DMD forces AA's to have a const type as
the key type. For example:
import std.stdio: writeln;
void main()
{
int[int[]] data;
writeln(typeid(data));
}
Prints: int[const(int)[]]
And your AA literal key type gets converted to a const type as well:
import std.stdio: writeln;
void main()
{
writeln(typeid([cast(char[])"foo" : 1]));
}
Prints: int[const(char)[]]
What happens here (if my interpretation is right), is that foo is first an
array of immutable chars, it's casted to a mutable array of chars, and then DMD
sees it is a key of an AA literal so it converts it to an array of const chars.
So DMD is most probably doing this:
On the left of assignment:
int[char[]] data
-> int[const(char)[]] data
On the right of assignment:
[cast(char[])const(char)[] : int]
-> int[cast(char[])const(char)[]]
-> int[char[]]
-> int[const(char)[]]
And the whole thing becomes:
int[const(char)[]] data = int[const(char)[]]
So if I got that right then DMD automatically changes the key type of an AA to
be const, regardless of any casts. Having to change int[] to const(int)[]
directly in the code would probably make the AA's harder to read, so maybe
that's a good thing.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4280] std.typecons.Tuple problem with one field
http://d.puremagic.com/issues/show_bug.cgi?id=4280 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2010-08-29 20:43:30 PDT --- This works fine in 2.048. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4767] New: dmd generates useless template bloat
http://d.puremagic.com/issues/show_bug.cgi?id=4767
Summary: dmd generates useless template bloat
Product: D
Version: D1 & D2
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nfx...@gmail.com
--- Comment #0 from nfx...@gmail.com 2010-08-29 20:36:13 PDT ---
Merely importing a file that contains template can make dmd generate code. This
not only increases compile times, but it also can be the reason for severe exe
bloat: often the linker will pull in completely unrelated modules just to get
symbols for instantiated templates (the bloat is then caused by unrelated
symbols that have been unnecessarily been pulled in).
$ cat a.d
module a;
import b;
$ cat b.d
module b;
struct Bloat(T)
{
void foo() {
}
}
class NotBloat
{
this(Bloat!(uint) x)
{
}
}
$ dmd -c a.d
$ nm a.o|grep Bloat
W _D1b12__T5BloatTkZ5Bloat3fooMFZv
V _D1b12__T5BloatTkZ5Bloat6__initZ
V _D32TypeInfo_S1b12__T5BloatTkZ5Bloat6__initZ
a.d only imports b.d, yet there's this crap in a.o.
Obviously dmd should not generate code in this case.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4325] invariant syntax isn't strict
http://d.puremagic.com/issues/show_bug.cgi?id=4325
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2010-08-29
20:01:39 PDT ---
The compiler will still print an error if you add any statements below a class
invariant, e.g.:
struct Foo {
invariant {}
}
struct Bar {
int x = 5;
invariant
assert(x == 1);
}
class CFoo {
invariant {}
}
class CBar {
invariant
}
void main()
{
Bar bar;
}
bug4325.d(7): Declaration expected, not 'assert'
So it might not be that bad. The same thing happens if you put "const" "pure"
"immutable" without any opening braces or colons, e.g.:
struct Foo {
pure
}
struct Bar {
const
}
class CFoo {
immutable
}
class CBar {
invariant
}
void main()
{
}
Compiles fine.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4414] [ICE] Taking item of static array returned by function
http://d.puremagic.com/issues/show_bug.cgi?id=4414 --- Comment #3 from Andrej Mitrovic 2010-08-29 19:52:22 PDT --- I forgot to mention this is on 2.048. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4414] [ICE] Taking item of static array returned by function
http://d.puremagic.com/issues/show_bug.cgi?id=4414
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #2 from Andrej Mitrovic 2010-08-29
19:52:03 PDT ---
This passes:
import std.stdio : writeln;
int[1] foo()
{
return [0];
}
void main()
{
int x = foo()[0];
writeln(typeid(x)); // writes int
//~ writeln(x);
}
But if I uncomment the last line then I get a different error:
Internal error: ..\ztc\cod2.c 4494
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4766] New: Function to load a whole HTML page
http://d.puremagic.com/issues/show_bug.cgi?id=4766
Summary: Function to load a whole HTML page
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-29 19:35:02 PDT ---
This page and the long (and partially wrong) D2 entry:
http://rosettacode.org/wiki/Web_scraping#D
shows that probably Phobos needs a simple function to download a whole HTML
page given just the URL. It's a common basic need.
See the Python version:
import urllib
page = urllib.urlopen("http://tycho.usno.navy.mil/cgi-bin/timer.pl";)
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4416] Function with ref argument breaks struct method const attribute
http://d.puremagic.com/issues/show_bug.cgi?id=4416
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2010-08-29
19:47:59 PDT ---
This also breaks immutable class objects, which is really bad:
void spam(ref int x)
{
x++;
}
class Foo
{
int x = 5;
void bar() immutable {
spam(x);
}
}
void main()
{
auto b = new immutable(Foo);
//~ b.x = 10; // uncommment for error
assert(b.x == 5);
b.bar();
assert(b.x == 6);
}
If you uncomment b.x = 10, you will of course get an error. Maybe raise this
bug to a higher priority?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4505] Type literal of pure function pointer inside function signature
http://d.puremagic.com/issues/show_bug.cgi?id=4505
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2010-08-29
19:11:49 PDT ---
I think this is a problem of the keyword pure trying to act as a type specifier
for the return type ( See also my bug 4734 for a similar issue).
If you put pure after the function definition but before the identifier, like
so:
pure int foo4(int function(int) pure func, int x) {
then your example compiles and all asserts pass.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4765] New: std.math.modf always returns 0
http://d.puremagic.com/issues/show_bug.cgi?id=4765
Summary: std.math.modf always returns 0
Product: D
Version: D2
Platform: x86_64
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: ether...@gmail.com
--- Comment #0 from Brandon Lyon 2010-08-29 19:31:16 PDT
---
The following code should output "3" but instead outputs "0". This is because,
regardless of the values sent to std.math.modf, the returned value is always 0.
I've used many combinations of values, but the result is always the same: 0. At
first I believed I was misusing the function and I noticed that the second
parameter was taken as a ref, so I performed the function call and checked 'b',
but it always stored the beginning value unchanged.
import std.stdio;
import std.math;
void main ()
{
real a = 9.,
b = 5.;
writeln(modf(a,b));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4765] std.math.modf always returns 0
http://d.puremagic.com/issues/show_bug.cgi?id=4765 --- Comment #1 from Brandon Lyon 2010-08-29 19:33:57 PDT --- Typo: Should return 4, not 3 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4534] Dmd crash with templates
http://d.puremagic.com/issues/show_bug.cgi?id=4534 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #2 from bearophile_h...@eml.cc 2010-08-29 19:03:33 PDT --- You are right, thank you very much. So I close this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4605] Wrong print of an int[string] aa
http://d.puremagic.com/issues/show_bug.cgi?id=4605 --- Comment #3 from bearophile_h...@eml.cc 2010-08-29 19:06:06 PDT --- Whitespace is important for readability, so instead of: [[5:6, 7:8]:2] It's better to print a space after the colon: [[5: 6, 7: 8]: 2] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4529] dmd crash with writeln of functions
http://d.puremagic.com/issues/show_bug.cgi?id=4529 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2010-08-29 19:03:02 PDT --- This affects 2.048 too. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4764] New: Lazy versions of std.string.split and std.string.splitlines
http://d.puremagic.com/issues/show_bug.cgi?id=4764 Summary: Lazy versions of std.string.split and std.string.splitlines Product: D Version: D2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: bearophile_h...@eml.cc --- Comment #0 from bearophile_h...@eml.cc 2010-08-29 19:01:29 PDT --- If you have a very large string that you need to split into its lines or parts lazily, you waste some memory if you use std.string.split or std.string.splitlines. So I suggest to add to std.string two ranges that work like std.string.split or std.string.splitlines but are lazy like std.algorithm.splitter(). std.algorithm.splitter() can't be used directly for this purpose because the semantic of std.string.split and std.string.splitlines is string-specific, they use three different kinds of newlines, and several different kinds of newspace (but the two new string functions may call std.algorithm.splitter() internally to reduce code duplication). The two new functions may be named for example std.string.lazySplit and std.string.lazySplitlines. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4534] Dmd crash with templates
http://d.puremagic.com/issues/show_bug.cgi?id=4534 Andrej Mitrovic changed: What|Removed |Added CC||andrej.mitrov...@gmail.com --- Comment #1 from Andrej Mitrovic 2010-08-29 19:00:50 PDT --- On 2.047 it causes that error, but on 2.048 it seems to be gone. I don't know how to close bug reports so you'll have to do it. :) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4605] Wrong print of an int[string] aa
http://d.puremagic.com/issues/show_bug.cgi?id=4605
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #2 from Andrej Mitrovic 2010-08-29
18:47:36 PDT ---
(In reply to comment #0)
> This D2 program, compiled with dmd 2.048b:
>
>
> import std.stdio;
> void main() {
> int[string] aa = ["10":10, "20":20];
> writeln(aa);
> }
>
>
> Prints (note the 1:10, that is a bug):
> 20:20 1:10
>
>
> The expected less buggy and less barbaric output is:
> ["10": 10, "20": 20]
> Or:
> ["20": 20, "10": 10]
It get's even worse:
import std.stdio;
void main() {
int[string] aa = ["100":1, "200":1, "300":1, "400":1];
writeln(aa);
}
Prints:
400:1 3:1 2:1 1:1
For your second code, I agree. I would prefer if D took an approach similar to
other languages and printed out something like:
[[5:6, 7:8]:2]
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4629] BufferedFile.printf() wants char[] as first argument
http://d.puremagic.com/issues/show_bug.cgi?id=4629
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2010-08-29
18:42:59 PDT ---
Casting a string literal to a char[] is esentially undefined behavior. If you
need a char[] out of a string literal, use .dup:
import std.stream: BufferedFile, FileMode;
void main()
{
auto f = new BufferedFile("testfile.t", FileMode.Out);
f.printf("%d\n".dup, 10);
f.close();
}
I'm guessing printf takes a char[] due to it's C heritage? So far I've seen a
lot of D1 code that uses char[] and when porting it to D2 one needs to either
change all declarations/arguments to use a string, or at the very least use
.dup when passing string literals to functions taking char[].
(In reply to comment #0)
> Using dmd 2.048 on this code:
>
>
> import std.stream: BufferedFile, FileMode;
> void main() {
> auto f = new BufferedFile("testfile.t", FileMode.Out);
> f.printf("%d\n", 10);
> f.close();
> }
>
>
> It shows the errors:
> test.d(4): Error: function std.stream.Stream.printf (char[] format,...) is not
> callable using argument types (string,int)
> test.d(4): Error: cannot implicitly convert expression ("%d\x0a") of type
> string to char[]
>
>
> This gives no errors:
> f.printf(cast(char[])"%d\n", 10);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4665] map with no automatic closure
http://d.puremagic.com/issues/show_bug.cgi?id=4665
Andrej Mitrovic changed:
What|Removed |Added
CC||andrej.mitrov...@gmail.com
--- Comment #1 from Andrej Mitrovic 2010-08-29
18:18:53 PDT ---
It does seem to be a delegate after all. If you try to evaluate it right there
it shows (notice the parantheses after the lambda definition):
import std.algorithm: map;
void main()
{
int n = 2;
map!( (double x){ return x * n; }() )([1.0, 2.0]);
}
Errors:
test.d(10): Error: expected 1 function arguments, not 0
test.d(10): Error: cannot evaluate delegate double(double x)
{
return x * cast(double)n;
}
() at compile time
This seems like a compiler bug. If you use a string instead, then it will work:
import std.algorithm: map;
void main()
{
string n = "2";
map!( (string x){ return x ~ n; } )(["1.0", "2.0"]);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4755] assert(0,"...") error message
http://d.puremagic.com/issues/show_bug.cgi?id=4755 bearophile_h...@eml.cc changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from bearophile_h...@eml.cc 2010-08-29 18:28:13 PDT --- You are right, thank you. I have erroneously compiled it in release mode. There is no bug here. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4763] New: Few possible changes on std.stdio.File
http://d.puremagic.com/issues/show_bug.cgi?id=4763
Summary: Few possible changes on std.stdio.File
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-29 16:57:23 PDT ---
This is not a bug report, it's a list of three possible small changes to the
code/API of std.stdio.File.
Here Andrei says that the std.stdio.File.open() method is useful for
performance:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.D&article_id=116278
Indeed inside File.this() there is an allocation, that open() may sometimes
save if File.Impl.refs is 1. But open() contains:
auto another = File(name, stdioOpenmode);
That calls File.this(), so at a first sight it seems that open() performs the
allocation anyway (if I am wrong then please ignore this).
Generally it's positive to minimize APIs. You may write:
auto f = File(...)
f = File(...)
Instead of:
auto f = File(...)
f.open(...)
--
According to D specs on the site, inner structs contain an extra scope pointer,
so this may be better:
private static struct Impl {
See also bug 4087
--
Given the presence of opAssign, I presume this code, inside open():
auto another = File(name, stdioOpenmode);
swap(this, another);
May be written just as:
this = File(name, stdioOpenmode);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4278] allow inlining of super calls (undo limitations of bug3500's fix)
http://d.puremagic.com/issues/show_bug.cgi?id=4278 Haruki Shigemori changed: What|Removed |Added CC||rayerd@gmail.com Depends on|3500|4728 --- Comment #3 from Haruki Shigemori 2010-08-29 17:07:10 PDT --- Probably depends on 4728 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4762] New: Textual representation of struct that doesn't define toString()
http://d.puremagic.com/issues/show_bug.cgi?id=4762
Summary: Textual representation of struct that doesn't define
toString()
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-29 15:57:55 PDT ---
This D2 program:
import std.stdio: writeln;
struct Foo { int x; string s; }
void main() {
Foo f = Foo(1.5, "hello");
writeln(f);
}
With DMD 2.048 it prints:
Foo
When a struct doesn't define a toString() I'd like (mostly for debugging
purposes) writeln/format to create a bit better textual representation, for
example it may show fields values:
Foo(x=1.5, s="hello")
See also bug 3813
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4761] std.array.mul()
http://d.puremagic.com/issues/show_bug.cgi?id=4761
--- Comment #1 from bearophile_h...@eml.cc 2010-08-29 15:44:13 PDT ---
This mul() needs more work, to be used on const arrays too. If you are
interested, I may try to write this improvement.
If the given array is one of the string types, it has to call
std.string.repeat() inside.
But the second argument of std.string.repeat() must become a signed integer,
otherwise you just need repeat("ab", -1) to create a crash.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4761] New: std.array.mul()
http://d.puremagic.com/issues/show_bug.cgi?id=4761
Summary: std.array.mul()
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: patch
Severity: enhancement
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-29 15:31:21 PDT ---
In Python I use very often the * (__mul__) list operator, it's handy in many
situations (it is not lazy):
>>> "abc" * -1
''
>>> "abc" * 0
''
>>> "abc" * 1
'abc'
>>> "abc" * 5
'abcabcabcabcabc'
>>> [0] * 5
[0, 0, 0, 0, 0]
It's not a good idea to add a similar product operator to D arrays because
despite vector mult operation will probably require [] (while the mul doesn't
require it), the two are too much syntactically close, they risk being too much
bug-prone.
So I suggest to simply add this mul() to std.array (this must be eager, not a
lazy range, otherwise it's not handy for its purposes):
/// ...
T[] mul(T)(T[] items, int times) {
T[] result;
static if(!is( typeof(items) == void[] )) {
if (times > 0 && items.length > 0) {
if (items.length == 1) {
result.length = times;
result[] = items[0];
} else {
result.length = items.length * times;
for (size_t pos; pos < result.length; pos += items.length)
result[pos .. pos+items.length] = items;
}
}
}
return result;
}
// demo --
import std.stdio;
void main() {
auto a1 = [0].mul(10);
writeln(a1);
auto a2 = [0, 5, 10].mul(4);
writeln(a2);
}
More unittests and a ddoct on request.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4760] New: core.atomic.atomicLoad() should be public
http://d.puremagic.com/issues/show_bug.cgi?id=4760 Summary: core.atomic.atomicLoad() should be public Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: druntime AssignedTo: s...@invisibleduck.org ReportedBy: dsim...@yahoo.com --- Comment #0 from David Simcha 2010-08-29 15:27:20 PDT --- Is there any reason why atomicLoad() isn't public in core.atomic? It's useful, presumably stable and already implemented. Lack of this being public has made me have to cut and paste snippets of the code into my std.parallelism module that's under review. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
