[Issue 2590] Deallocator is not called if constructor fails.
http://d.puremagic.com/issues/show_bug.cgi?id=2590 --- Comment #7 from Justin Spahr-Summers 2010-04-05 21:14:23 CDT --- (In reply to comment #6) > > Not that I disagree this bug is obsolete, but what would you call delete on? > With the failed construction, you never got a pointer to the class data. > > If class allocators were to be saved, I think the correct behavior on a failed > constructor should be to call the deallocator. Fair point. I didn't realize that it's impossible to hold onto the pointer. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4070] prefix const on member functions considered confusing
http://d.puremagic.com/issues/show_bug.cgi?id=4070 Steven Schveighoffer changed: What|Removed |Added CC||schvei...@yahoo.com --- Comment #2 from Steven Schveighoffer 2010-04-05 13:44:02 PDT --- The point is that it's confusing, not inconsistent. It's confusing to read since the this parameter is hidden. Yes, it's consistent and unambiguous, but it's confusing. It's your prerogative not to disallow the syntax, but keep in mind that allowing the const before a function that returns a type will result in most style guides advising against it because it's too confusing. Effectively, the fact that it's confusing will negate its usage. Isn't one of the goals of the programming language to come up with consistent, *sensible* syntax? This is compounded by the fact that the const qualifier has an alternative location. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4070] prefix const on member functions considered confusing
http://d.puremagic.com/issues/show_bug.cgi?id=4070
Walter Bright changed:
What|Removed |Added
Status|NEW |RESOLVED
CC||bugzi...@digitalmars.com
Resolution||WONTFIX
--- Comment #1 from Walter Bright 2010-04-05
12:43:18 PDT ---
It's current behavior is consistent. Const without parentheses applies to the
outermost declaration. So, for:
const foo* bar();
the const applies to the outermost part of the type, which would be the
function type, not the function return type.
The following syntactical usages of const all have the same meaning:
const:
foo* bar();
and:
const {
foo* bar();
}
and:
const foo* bar();
as all attributes behave the same way.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4070] New: prefix const on member functions considered confusing
http://d.puremagic.com/issues/show_bug.cgi?id=4070
Summary: prefix const on member functions considered confusing
Product: D
Version: 2.041
Platform: Other
OS/Version: Windows
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas 2010-04-05 10:26:45
PDT ---
struct foo {
const foo* bar( ) const {
return new foo;
}
}
This function does not return a const foo, as one might expect. Rather, it is
twice specified that this function does not change any members of foo.
This is troublesome because, everywhere but in a function declaration, const
foo* would be equivalent to const( foo* ). It is hence a source of confusion
and inconsistency.
If this is a case of unfortunate C++ inheritance, please make const foo bar( )
an error, and enforce the use of parentheses. If not, get rid of it.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4069] New: std.xml.Document.pretty saves empty elements with spaces and line breaks
http://d.puremagic.com/issues/show_bug.cgi?id=4069
Summary: std.xml.Document.pretty saves empty elements with
spaces and line breaks
Product: D
Version: unspecified
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: r.sagita...@gmx.de
--- Comment #0 from Rainer Schuetze 2010-04-05 10:11:32
PDT ---
Test case:
import std.stdio;
import std.xml;
import std.string;
void main() {
auto doc = new Document(new Tag("root"));
doc ~= new Element("elem", "");
string s = join(doc.pretty(1),"");
writefln("doc: '%s'", s);
auto xml = new Document(s);
string t = xml.elements[0].text();
writefln("elem: '%s'", t);
assert(t == "");
}
outputs:
doc: ' '
elem: ' '
core.exception.asserter...@test(17): Assertion failure
This does not happen with non-empty elements or with Document.toString
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4069] std.xml.Document.pretty saves empty elements with spaces and line breaks
http://d.puremagic.com/issues/show_bug.cgi?id=4069
Rainer Schuetze changed:
What|Removed |Added
Keywords||patch, wrong-code
--- Comment #1 from Rainer Schuetze 2010-04-05 10:13:53
PDT ---
Here's a patch that switches to the short form of an empty element:
Index: xml.d
===
--- xml.d(revision 1476)
+++ xml.d(working copy)
@@ -887,7 +887,7 @@
return buffer;
}
-override bool isEmptyXML() { return false; } /// Returns false always
+override bool isEmptyXML() { return items.length == 0; }
}
}
The resulting output is:
doc: ' '
elem: ''
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4068] Returning references to const members yield error message
http://d.puremagic.com/issues/show_bug.cgi?id=4068 Simen Kjaeraas changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Simen Kjaeraas 2010-04-05 10:09:50 PDT --- (In reply to comment #1) > This probably is invalid, because the const in that position applies to the > this pointer. It's equivalent to: > [...] > These kinds of errors are why I think allowing const at the beginning of the > function should be deprecated. Indeed. Closing this one. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3201] std.xml incorrectly converts symbols in attributes, & -> & amp
http://d.puremagic.com/issues/show_bug.cgi?id=3201 Rainer Schuetze changed: What|Removed |Added Keywords||patch CC||r.sagita...@gmx.de --- Comment #2 from Rainer Schuetze 2010-04-05 10:03:14 PDT --- As the test case was the same in #3200, I've attached the patch that fixes both there -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3200] std.xml doesn't follow spec for Tag.text
http://d.puremagic.com/issues/show_bug.cgi?id=3200
Rainer Schuetze changed:
What|Removed |Added
Keywords||patch
CC||r.sagita...@gmx.de
--- Comment #1 from Rainer Schuetze 2010-04-05 09:44:15
PDT ---
This is caused by encode and decode being inverted for attributes and the the
element text never being decoded. Here is a patch
Index: xml.d
===
--- xml.d(revision 1476)
+++ xml.d(working copy)
@@ -991,7 +991,7 @@
reqc(s,'=');
munch(s,whitespace);
reqc(s,'"');
-string val = encode(munch(s,"^\""));
+string val = decode(munch(s,"^\""));
reqc(s,'"');
munch(s,whitespace);
attr[key] = val;
@@ -1088,7 +1088,7 @@
{
string s = "<" ~ name;
foreach(key,val;attr)
-s ~= format("
%s=\"%s\"",key,decode(val,DecodeMode.LOOSE));
+s ~= format(" %s=\"%s\"",key,encode(val.dup)); //
decode(val,DecodeMode.LOOSE));
return s;
}
@@ -1945,7 +1945,7 @@
invariant(char)* p = startTag.tagString.ptr
+ startTag.tagString.length;
invariant(char)* q = tag_.tagString.ptr;
-text = p[0..(q-p)];
+text = decode(p[0..(q-p)]);
auto element = new Element(startTag);
if (text.length != 0) element ~= new Text(text);
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4068] Returning references to const members yield error message
http://d.puremagic.com/issues/show_bug.cgi?id=4068
Steven Schveighoffer changed:
What|Removed |Added
CC||schvei...@yahoo.com
--- Comment #1 from Steven Schveighoffer 2010-04-05
07:13:07 PDT ---
This probably is invalid, because the const in that position applies to the
this pointer. It's equivalent to:
ref int bar() const {
To get the desired behavior, use parentheses:
ref const(int) bar() {
These kinds of errors are why I think allowing const at the beginning of the
function should be deprecated.
One strange thing, this also has same error:
ref const int bar() {
It would follow logically that if const applies to the function bar and not the
return value, then ref applies to the function bar as well, but it obviously
only applies to the return value.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4068] New: Returning references to const members yield error message
http://d.puremagic.com/issues/show_bug.cgi?id=4068
Summary: Returning references to const members yield error
message
Product: D
Version: 2.041
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: simen.kja...@gmail.com
--- Comment #0 from Simen Kjaeraas 2010-04-05 05:57:30
PDT ---
The following should IMO compile:
struct S {
const int n;
const ref int bar( ) {
return n;
}
}
It fails on the line 'return n;', with the message 'Error: can only initialize
const member n inside constructor'
The same behavior exists with immutable members and references.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4067] New: [CTFE] Maybe ignored code in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4067
Summary: [CTFE] Maybe ignored code in CTFE
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-05 05:52:22 PDT ---
Usually I show here minimal programs that contain the bug, but this time I show
a bigger small program.
This is a small benchmark I've adapted from the old Shootout code, it tests the
performance of exceptions (on dmd they are very slow).
I use this code both at compile time and run time.
It contains a printf and exceptions that can't be used in CTFE, but this
program compiles with dmd v.2.042 and prints 0/0 at ctfe.
import std.c.stdio: printf;
class LoException : Exception {
this() {
super(null);
}
}
class HiException : Exception {
this() {
super(null);
}
}
struct HiLo { int hi, lo; }
struct App {
int hi, lo, count;
void someFunction() {
try {
hiFunction();
} catch (Exception e) {
printf("We shouldn't get here\n");
}
}
void hiFunction() {
try {
loFunction();
} catch (HiException) {
hi++;
}
}
void loFunction() {
try {
blowUp();
} catch (LoException) {
lo++;
}
}
void blowUp() {
if (count & 1)
throw new HiException();
else
throw new LoException();
}
auto go(int n) {
for (count = 0; count < n; count++)
someFunction();
return HiLo(hi, lo);
}
}
void main() {
enum int n = 1000;
App app;
HiLo result1 = app.go(n); // OK
printf("excepts(%d) hi|lo = %d | %d\n", n, result1.hi, result1.lo);
enum HiLo result2 = app.go(n); // Err
printf("excepts(%d) hi|lo = %d | %d\n", n, result2.hi, result2.lo);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4066] New: [ICE] enum AA get
http://d.puremagic.com/issues/show_bug.cgi?id=4066
Summary: [ICE] enum AA get
Product: D
Version: future
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-04-05 05:44:14 PDT ---
void main() {
enum int[string] aa = ["aa":1, "bb":2];
string s = "xx";
int r = aa.get(s, -1);
}
dmd 2.042 gives:
Internal error: e2ir.c 4600
The error vanishes if aa is not an enum.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4065] New: [CTFE] AA "in" operator doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=4065
Summary: [CTFE] AA "in" operator doesn't work
Product: D
Version: future
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-04-05 05:41:16 PDT ---
bool foo(string s) {
enum int[string] aa = ["aa":1, "bb":2];
return cast(bool)(s in aa);
}
enum bool r = foo("xx");
void main() {}
dmd 2.042 gives:
test.d(3): Error: Cannot interpret s in (["aa":1,"bb":2]) at compile time
test.d(5): Error: cannot evaluate foo("xx") at compile time
test.d(5): Error: cannot evaluate foo("xx") at compile time
I have tagged this as major bug because it limits a lot the uses of AAs in
CTFE. And AA.get too is not available yet at compile-time.
I presume this is caused by the pointers that are not available yet at
compile-time.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4064] New: [CTFE] array.reverse doesn't work
http://d.puremagic.com/issues/show_bug.cgi?id=4064
Summary: [CTFE] array.reverse doesn't work
Product: D
Version: future
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-04-05 05:32:09 PDT ---
bool foo(int[] arr) {
arr.reverse;
return arr == [2, 1];
}
enum bool r = foo([1, 2]);
void main() {}
dmd 2.042 gives:
test.d(2): Error: cannot evaluate _adReverse(arr,4u) at compile time
test.d(5): Error: cannot evaluate foo([1,2]) at compile time
test.d(5): Error: cannot evaluate foo([1,2]) at compile time
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4063] New: [CTFE] key not found in AA gives bad error message
http://d.puremagic.com/issues/show_bug.cgi?id=4063
Summary: [CTFE] key not found in AA gives bad error message
Product: D
Version: future
Platform: x86
OS/Version: Windows
Status: NEW
Keywords: diagnostic
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-04-05 05:29:45 PDT ---
int foo(string s) {
enum int[string] aa = ["aa":1, "bb":2];
return aa[s];
}
enum _ = foo("xx"); // line 5
void main() {}
dmd 2.042 gives:
test.d(5): Error: cannot evaluate foo("xx") at compile time
test.d(5): Error: cannot evaluate foo("xx") at compile time
A much better pair of error messages can be:
test.d(3): Error: Range violation. Key "xx" not found in associative array
'aa'.
test.d(5): Error: cannot evaluate foo("xx") at compile time.
Or just (if the symmetry with the run-time error is not considered important):
test.d(3): key "xx" not found in associative array 'aa'.
test.d(5): Error: cannot evaluate foo("xx") at compile time.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2590] Deallocator is not called if constructor fails.
http://d.puremagic.com/issues/show_bug.cgi?id=2590 --- Comment #6 from Steven Schveighoffer 2010-04-05 04:43:18 PDT --- (In reply to comment #5) > > But the allocator is *not* called automatically, strictly speaking. 'new' is > your call to the allocator. Since you use malloc() instead of the garbage > collector, 'delete' then becomes necessary. > > Under normal circumstances, an exception thrown during construction wouldn't > leak memory because the garbage collector would eventually collect it; in your > code, you took on the task of manually allocating and deallocating memory for > objects of class C. It makes sense to me that such custom allocation would > entail finer management of exceptional situations. Not that I disagree this bug is obsolete, but what would you call delete on? With the failed construction, you never got a pointer to the class data. If class allocators were to be saved, I think the correct behavior on a failed constructor should be to call the deallocator. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4062] New: can call method without this pointer inside is()
http://d.puremagic.com/issues/show_bug.cgi?id=4062
Summary: can call method without this pointer inside is()
Product: D
Version: 1.057
Platform: Other
OS/Version: All
Status: NEW
Keywords: accepts-invalid, rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nfx...@gmail.com
--- Comment #0 from nfx...@gmail.com 2010-04-05 03:47:40 PDT ---
The following compiles. Not sure if this is a bug or a feature, so I'm
reporting this as a bug. Close as invalid if it's actually a feature.
class X {
void x(int a) {
}
}
void main() {
static assert(is( typeof({ X.x(1); }) ));
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4060] Phobos + linux problems with files > 2GB
http://d.puremagic.com/issues/show_bug.cgi?id=4060 Justin Spahr-Summers changed: What|Removed |Added CC||justin.spahrsumm...@gmail.c ||om --- Comment #1 from Justin Spahr-Summers 2010-04-05 03:06:44 CDT --- This strikes me as a mistake in the Phobos declaration of seek(). The underlying stdio fseek() function can only take longs as offsets, and Phobos' seek() is defined the same way; however, a 'long' in C almost always corresponds to an 'int' in D. It's definitely a bug one way or the other, but to work around it you may want to use offsets from SEEK_CUR instead of SEEK_SET. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
