[Issue 3985] Documentation of the main() Function
http://d.puremagic.com/issues/show_bug.cgi?id=3985 bearophile_h...@eml.cc changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #1 from bearophile_h...@eml.cc 2010-03-19 09:02:34 PDT --- The compiler is OK. It's just a little problem in the D2 docs. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3986] New: Struct constructors bypass default initialization of member variables
http://d.puremagic.com/issues/show_bug.cgi?id=3986
Summary: Struct constructors bypass default initialization of
member variables
Product: D
Version: 2.036
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: blocker
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2010-03-19 16:13:43 PDT ---
If a struct constructor is called implicitly, member variables are
not default initialized. Applies to D2.036 and later.
Here's a simple test case with an assert that fails. (Beware: this test case
doesn't capture the more complex case where one of the members is itself a
struct with a constructor). I'm pretty sure the problem is in declaration.c,
around line 1140.
struct SiberianHamster
{
int rat = 813;
this(string z) { }
}
void main()
{
SiberianHamster basil = cybil;
assert(basil.rat == 813);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 1079] gdb: Dwarf Error: Cannot find DIE at 0xb705 referenced from DIE at 0x250
http://d.puremagic.com/issues/show_bug.cgi?id=1079 Robert Clipsham rob...@octarineparrot.com changed: What|Removed |Added CC||rob...@octarineparrot.com --- Comment #18 from Robert Clipsham rob...@octarineparrot.com 2010-03-19 16:34:02 PDT --- http://d.puremagic.com/issues/show_bug.cgi?id=3987 Is related to this bug, if not a duplicate. I'd also like to note that all the DW_TAG_unknown errors when using -g rather than -gc are non-bugs, as that is expected until gdb supports D's extensions to DWARF. If you get them when using -gc it is a dmd issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3987] New: [gdb] Invalid DWARF output for function pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3987
Summary: [gdb] Invalid DWARF output for function pointers
Product: D
Version: 1.055
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: rob...@octarineparrot.com
--- Comment #0 from Robert Clipsham rob...@octarineparrot.com 2010-03-19
16:18:50 PDT ---
The following program causes dmd to produce invalid DWARF output, rendering the
program impossible to debug with gdb:
void function() myfunc;
void main(){}
When compiled with either -g or -gc, causes this error in gdb when setting a
breakpoint (eg b _Dmain):
Die: DW_TAG_padding (abbrev = 0, offset = 0)
has children: FALSE
attributes:
Dwarf Error: Cannot find type of die [in module /tmp/test]
From what I can gather, the DWARF output is correct (objdump --dwarf gives no
errors), but the padding before .debug_info is incorrect, causing gdb to be
unable to read it properly.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3988] New: Provide canonical example for operator overloading
http://d.puremagic.com/issues/show_bug.cgi?id=3988
Summary: Provide canonical example for operator overloading
Product: D
Version: 2.041
Platform: All
URL: http://digitalmars.com/d/2.0/operatoroverloading.html
OS/Version: All
Status: NEW
Keywords: spec
Severity: normal
Priority: P1
Component: www.digitalmars.com
AssignedTo: nob...@puremagic.com
ReportedBy: jlqu...@optonline.net
--- Comment #0 from Jerry Quinn jlqu...@optonline.net 2010-03-19 23:19:43 PDT
---
At first glance, the new operator overloading syntax looks cumbersome by
comparison to C++. Adding the following example to the D docs would make it
clear what the advantage of the new syntax is, as well as not requiring people
to reinvent it repeatedly:
http://www.digitalmars.com/webnews/newsgroups.php?art_group=digitalmars.Darticle_id=101636
2. Use one mixin expression:
T opBinary(string op)(T rhs) {
return mixin(data ~op~ rhs.data);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3986] Struct constructors bypass default initialization of member variables
http://d.puremagic.com/issues/show_bug.cgi?id=3986 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||patch --- Comment #1 from Don clugd...@yahoo.com.au 2010-03-20 00:26:22 PDT --- PATCH: In VarDeclaration::semantic, it should be doing a blit of the default initializer before it calls the constructor. Currently it only does that for explicit constructor calls. This bug as a blocker, since it makes struct invariants unusable: if a struct with a class invariant is used as a member of another struct, the invariant will fail on first use of that struct. Index: declaration.c === --- declaration.c(revision 418) +++ declaration.c(working copy) @@ -1139,6 +1139,14 @@ // Rewrite as e1.ctor(arguments) Expression *ector = new DotIdExp(loc, e1, Id::ctor); ei-exp = new CallExp(loc, ector, ei-exp); +/* Before calling the constructor, initialize + * variable with a bit copy of the default + * initializer + */ +Expression *e = new AssignExp(loc, e1, t-defaultInit(loc)); +e-op = TOKblit; +e-type = t; +ei-exp = new CommaExp(loc, e, ei-exp); } else /* Look for opCall -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3990] New: Deferencing a dynamic array as pointer
http://d.puremagic.com/issues/show_bug.cgi?id=3990
Summary: Deferencing a dynamic array as pointer
Product: D
Version: 2.041
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-03-20 05:57:22 PDT ---
This D2 code is currrently allowed, but I think it has to become a syntax
error, dynamic arrays are not pointers:
void main() {
int[] a1 = [5, 4, 3];
assert(*a1 == 5);
alias typeof(a1) T1;
assert(is(typeof(*T1)));
int* p1 = cast(int*)a1;
assert(p1 == a1.ptr);
}
Similar code can be written for a fixed-size array like:
int[3] a2 = [5, 4, 3];
For fixed-size arrays such conversions to pointers can be more acceptable.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3991] New: Void initializers in unions considered overlapping
http://d.puremagic.com/issues/show_bug.cgi?id=3991
Summary: Void initializers in unions considered overlapping
Product: D
Version: 1.057
Platform: All
OS/Version: All
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: matti.niemenmaa+dbugzi...@iki.fi
--- Comment #0 from Matti Niemenmaa matti.niemenmaa+dbugzi...@iki.fi
2010-03-20 10:06:59 PDT ---
Each of the following unions give the same error:
arst.d(1): Error: union arst.X overlapping initialization for struct X.y
arst.d(5): Error: union arst.Y overlapping initialization for struct Y.y
arst.d(9): Error: union arst.Z overlapping initialization for struct Z.y
union X {
int x = void;
int y = void;
}
union Y {
int x = void;
int y = 0;
}
union Z {
int x = 0;
int y = void;
}
Removing the = void, these unions compile (except, for some reason, Y, but
that's a separate issue).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3994] New: Wrong line numbers inside AA/Array initializers
http://d.puremagic.com/issues/show_bug.cgi?id=3994
Summary: Wrong line numbers inside AA/Array initializers
Product: D
Version: 1.050
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: diagnostic, wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: cbkbbej...@mailinator.com
Blocks: 977
--- Comment #0 from Nick Sabalausky cbkbbej...@mailinator.com 2010-03-20
12:15:03 PDT ---
--
import std.stdio;
void main()
{
int i;
auto arr = [
i,
__LINE__,//xxx, // Expected number of this line
i
]; // Outputs this line number
writeln(arr[1]);
}
--
void main()
{
int i;
auto arr = [
i,
xxx, // Error should be reported here
i
]; // Error actually reported here
}
--
The above problem holds for both arrays and assoc arrays. Problem does not
occur for array literals or assoc array literals.
This is a real pain for a particular idiom I find very useful, particularly for
handling domain-specific languages:
--
auto dgMap = [
foo: (Foo f) {
return /+..stuff..+/;
},
bar: (Foo f) {
return /+..stuff..+/;
},
bat: (Foo f) {
return /+..stuff..+/;
},
];
dgMap[bar](new Foo())
--
Issue #977 is a special case of this issue.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3995] Can't access array/AA from function literal defined inside the array/AA's initializer
http://d.puremagic.com/issues/show_bug.cgi?id=3995
--- Comment #1 from Nick Sabalausky cbkbbej...@mailinator.com 2010-03-20
12:48:27 PDT ---
The above example might have a problem inferring the return type of the
delegate literals (and therefore the type of 'dgMap' itself). But this
alteration doesn't have that problem and still fails to compile with undefined
identifier dgMap:
-
auto dgMap = [
foo: delegate int(int i) {
if(i 1)
return 0;
else
return dgMap[foo](i-1);
},
bar: delegate int(int i) {
return dgMap[foo](7);;
}
];
-
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
