[Issue 4302] Regression(2.046, 1.061): compiler errors using startsWith in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4302
Don changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Don 2010-08-20 22:30:55 PDT ---
The cause of the regression was this line at the end of
TemplateInstance::semantic()
around line 3980:
if (global.gag)
{ // Try to reset things so we can try again later to instantiate it
tempdecl->instances.remove(tempdecl_instance_idx);
+semanticRun = 0;
+inst = NULL;
}
This code was added in svn 477, to fix bug 4042.
BUT... removing those lines, bug 4042 still passes, and the test suite still
passes. So patch option #1 is to simply remove them.
Patch option #2: If those lines should really remain, then we should definitely
not reset for a later attempt, if the instantiation was made from inside a
static if. You only get chance at a static if.
Note that template constraints set the SCOPEstaticif flag.
// template.c, line 3982.
if (global.gag)
{ // Try to reset things so we can try again later to instantiate it
tempdecl->instances.remove(tempdecl_instance_idx);
+ if (!(sc->flags & SCOPEstaticif))
+ {
semanticRun = 0;
inst = NULL;
+ }
}
Thirdly, it is in fact possible that what we're seeing is a consequence of
bug4269, ie is a bug in is(). If so, then this patch is just a temporary
workaround until that deeper bug is fixed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4302] Regression(2.046, 1.061): compiler errors using startsWith in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=4302
Don changed:
What|Removed |Added
Version|D2 |D1 & D2
Summary|Regression(2.046): compiler |Regression(2.046, 1.061):
|errors using startsWith in |compiler errors using
|CTFE|startsWith in CTFE
--- Comment #2 from Don 2010-08-20 22:25:27 PDT ---
Reduced test case shows it doesn't require template constraints, and applies to
D1 as well. Passes on D1.060, fails on D1.061.
-
template fail4302() {
static assert(0);
}
template bug4302() {
alias fail4302!() bad;
}
static if (is(bug4302!())) {}
// And this case broke one of my early attempts to fix it
template tough4302()
{
template bar()
{
template far()
{
static assert(0);
}
alias far!() par;
}
static if (is(bar!())) {}
}
alias tough4302!() tougher;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4698] Can't add constraints to templated class that uses inheritance
http://d.puremagic.com/issues/show_bug.cgi?id=4698 Kosmonaut changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Comment #2 from Kosmonaut 2010-08-20 20:55:45 PDT --- *** This issue has been marked as a duplicate of issue 3673 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3673] inheritance + if clause = no go
http://d.puremagic.com/issues/show_bug.cgi?id=3673 Kosmonaut changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #4 from Kosmonaut 2010-08-20 20:55:45 PDT --- *** Issue 4698 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 4698] Can't add constraints to templated class that uses inheritance
http://d.puremagic.com/issues/show_bug.cgi?id=4698
Kosmonaut changed:
What|Removed |Added
CC||kosmon...@tempinbox.com
--- Comment #1 from Kosmonaut 2010-08-20 20:52:33 PDT
---
This works:
---
class Foo {}
class Bar(T) if(isInputRange!T) : Foo {}
---
I'm pretty sure that someone already filled a bug about this issue. Couldn't
find it though.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681
--- Comment #7 from David Simcha 2010-08-20 18:43:24 PDT ---
Comment from Shin Fujishiro the Phobos mailing list, reproduced here to make it
more public and permanent:
Seems like a bug of Appender.writeCapacity(). It often writes 'cap' to
wrong address; the following assertion fails:
==
diff --git phobos/std/array.d phobos/std/array.d
index 6b62733..e6d3a62 100644
--- phobos/std/array.d
+++ phobos/std/array.d
@@ -736,10 +736,12 @@ private:
auto p = cast(ubyte*) (pArray.ptr + pArray.length);
if (cap < ubyte.max)
{
+assert(p + 1 <= GC.addrOf(pArray.ptr) + GC.sizeOf(pArray.ptr));
*p = cast(ubyte) cap;
}
else if (cap < ushort.max)
{
+assert(p + 3 <= GC.addrOf(pArray.ptr) + GC.sizeOf(pArray.ptr));
*p++ = ubyte.max;
*p++ = cast(ubyte) cap;
*p++ = cast(ubyte) (cap >> 8);
==
Shin
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4681] Appender access violation
http://d.puremagic.com/issues/show_bug.cgi?id=4681 --- Comment #6 from David Simcha 2010-08-20 18:10:15 PDT --- (In reply to comment #5) > Deterministic test case (always crash on my machine): Apparently this test case is deterministic only on your machine. On my machine it doesn't reproduce this bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4675] Eponymous Template should hide internal names
http://d.puremagic.com/issues/show_bug.cgi?id=4675
--- Comment #3 from Torarin 2010-08-20 17:54:25 PDT ---
Yes. std.traits deals with it by doing
private template hasRawAliasing(T...)
{
enum hasRawAliasing
= hasRawPointerImpl!(RepresentationTypeTuple!(T)).result;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4698] New: Can't add constraints to templated class that uses inheritance
http://d.puremagic.com/issues/show_bug.cgi?id=4698
Summary: Can't add constraints to templated class that uses
inheritance
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha 2010-08-20 17:48:36 PDT ---
import std.range;
class Foo {}
class Bar(T) : Foo if(isInputRange!T) {}
test9.d(4): members expected
test9.d(4): { } expected following aggregate declaration
test9.d(4): Declaration expected, not 'if'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4675] Eponymous Template should hide internal names
http://d.puremagic.com/issues/show_bug.cgi?id=4675 --- Comment #2 from Andrej Mitrovic 2010-08-20 17:35:05 PDT --- There are more cases of contradiction, but I think this has to do with some of the spec not being updated. In other cases some features are simply not yet implemented.. My guess is that this feature should be implemented like it states in TDPL. Otherwise for any non-trivial templates you would have to write code like: isNumeric!(int).isNumeric -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4693] std.range.iota fails with long type
http://d.puremagic.com/issues/show_bug.cgi?id=4693 David Simcha changed: What|Removed |Added CC||dsim...@yahoo.com --- Comment #1 from David Simcha 2010-08-20 17:28:17 PDT --- I can't reproduce this on the current SVN version of Phobos. Iota has been majorly debugged lately. What version of DMD/Phobos are you using? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4675] Eponymous Template should hide internal names
http://d.puremagic.com/issues/show_bug.cgi?id=4675
Torarin changed:
What|Removed |Added
CC||tora...@gmail.com
--- Comment #1 from Torarin 2010-08-20 17:26:26 PDT ---
I ran into trouble with this example as well, but this time because what should
work, doesn't:
import std.stdio;
template isNumeric(T)
{
enum bool test1 = is(T : long);
enum bool test2 = is(T : real);
enum bool isNumeric = test1 || test2;
}
void main()
{
bool a = isNumeric!int;
}
Fails with:
test.d(12): Error: expression isNumeric!(int) is void and has no value.
I was surprised to find that the language reference actually contradicts TDPL
here:
"Implicit Template Properties
If a template has exactly one member in it, and the name of that member is the
same as the template name, that member is assumed to be referred to in a
template instantiation."
(In reply to comment #0)
>
> According to TDPL, calling isNumeric!(T) is rewritten by the compiler to
> isNumeric!(T).isNumeric, therefore hiding access to any other names.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 2958] std.getopt RangeError on missing arg
http://d.puremagic.com/issues/show_bug.cgi?id=2958 David Simcha changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC||dsim...@yahoo.com Resolution||FIXED --- Comment #1 from David Simcha 2010-08-20 17:20:16 PDT --- http://dsource.org/projects/phobos/changeset/1905 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4697] New: std.demangle doesn't work correctly
http://d.puremagic.com/issues/show_bug.cgi?id=4697
Summary: std.demangle doesn't work correctly
Product: D
Version: D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: necrom...@gmail.com
--- Comment #0 from Max Klyga 2010-08-20 16:10:03 PDT ---
import std.demangle, std.stdio;
void main() {
auto a = (float x, char y) { return 0; };
auto b = [ 1, 2, 3 ];
auto c = 3.5;
writeln(demangle(a.mangleof));
writeln(demangle(b.mangleof));
writeln(demangle(c.mangleof));
writeln(demangle("_D3std4math3cosFNaNbeZe"));
writeln(demangle("_D3std3utf6toUTF8FG4awZAa"));
writeln(demangle("_D3std6string7sformatFAaYAa"));
}
output:
DFfaZi
Ai
d
_D3std4math3cosFNaNbeZe
char[] std.utf.toUTF8(char[4], dchar)
char[] std.string.sformat(char[], ...)
So it does unmangle some of the symbols, but it's very limited currently.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4696] New: function pointers to std.math functions cause linking errors
http://d.puremagic.com/issues/show_bug.cgi?id=4696
Summary: function pointers to std.math functions cause linking
errors
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: necrom...@gmail.com
--- Comment #0 from Max Klyga 2010-08-20 15:50:19 PDT ---
import std.math;
void main() {
auto x = [ &sin, &cos ];
}
output:
prog.o: In function `_Dmain':
prog.d:(.text._Dmain+0x4): undefined reference to `_D3std4math3cosFNaNbeZe'
prog.d:(.text._Dmain+0xa): undefined reference to `_D3std4math3sinFNaNbeZe'
collect2: ld returned 1 exit status
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4695] New: std.range.zip is broken
http://d.puremagic.com/issues/show_bug.cgi?id=4695
Summary: std.range.zip is broken
Product: D
Version: D2
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: necrom...@gmail.com
--- Comment #0 from Max Klyga 2010-08-20 15:12:41 PDT ---
import std.range;
void main() {
auto a = [ 1, 2, 3 ];
immutable b = [ 1, 2, 3 ];
zip(a, b);
}
outputs:
src/phobos/std/range.d(1732): Error: can only initialize const member
_field_field_1 inside constructor
import std.range;
void main() {
auto a = [ 1, 2, 3 ];
auto b = [ 'a', 'b', 'c' ];
zip(a, b);
}
outputs:
src/phobos/std/range.d(1773): Error: front(this.ranges._field_field_1) is not
an lvalue
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4694] Unused last assignment warning
http://d.puremagic.com/issues/show_bug.cgi?id=4694 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmail.com --- Comment #2 from Jonathan M Davis 2010-08-20 15:08:49 PDT --- I'm okay with this as long as it gives no false positives. Unlike with the variable initialization issue, where you might have to initialize something when you don't need to, a false positive in this case would result in having to remove an assignment that you needed. Presumably, if this were implemented, it would not be done in a manner that that would ever happen. So, given that, it seems like a fine request to me. I don't think that it's something that would help me much, but it wouldn't hurt. The main question, however, is whether Walter would ever even considering it, since one, he hates warnings, and two, this involves code flow analysis which he generally avoids. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4694] Unused last assignment warning
http://d.puremagic.com/issues/show_bug.cgi?id=4694 --- Comment #1 from bearophile_h...@eml.cc 2010-08-20 14:54:07 PDT --- Answers to a comment by Jonathan M Davis: Okay. Giving a warning for an unused variable makes sense. However, giving a warning for setting it somewhere that is not where it is declared doesn't make sense. Sure, in this case, it's dumb of the programmer to have done that, but 1. The compiler should be able to optimize out such a simple case. 2. More complex cases much harder to detect, and it's not all that hard for you to _want_ to disconnect the declaration of the variable and initializing it - likely because of scoping issues or conditional blocks. The compiler is only going to be able to detect the simplest cases, and as I said in #1, such simple cases will likely get optimized away. Cases too complex to optimize away are going to be much harder for the compiler to detect, and if you start going that far, you're getting to the point where you just about should have done what Java did and force initialization of variables rather than default initialize them. Not initializing a variable yourself, and the setting it later with a value that you could have set it to at its declaration is not a coding error. It may not be best practice, but it's not going to result in an error. So, I don't think that it makes any sense to make it a warning. --- > However, giving a warning for setting it somewhere that is not where it is > declared doesn't make sense. This is not the purpose of this warning. The purpose of this warning is to spot situations where you assign something to a variable and then you forget to use such contents. It's kind of the opposite of the unused variable. > 1. The compiler should be able to optimize out such a simple case. The compiler is often able to remove dead code, but the purpose of this warning is to detect a point where code is written badly (no need for an operation) or it's a possible sign of a spot where the programmer has forgotten to use a variable. > 2. More complex cases much harder to detect, This is true, but this is just a warning, it's not a change in the language, so even if the compiler is not able to spot the most complex situations, it's OK still. A partial help against bugs is better than no help. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3960] Unused variable warning
http://d.puremagic.com/issues/show_bug.cgi?id=3960 --- Comment #4 from bearophile_h...@eml.cc 2010-08-20 14:48:59 PDT --- Sorry, my mistake, I have lumped two different warnings into this enhancement request, so please ignore comment 2 I have moved the second warning to bug 4694 Look at bug 4694 for an answer to comment 3 regarding the second warning. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4673] Bug in std.string (isNumeric)
http://d.puremagic.com/issues/show_bug.cgi?id=4673 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmail.com --- Comment #7 from Jonathan M Davis 2010-08-20 14:42:21 PDT --- I though that they were doing the same with complex numbers that they did with associative arrays, which was to remove it from the language itself but have the compiler use a library solution for it (kind of like it using the object module with Object in it rather than just knowing the definition). So, the syntax would be the same, but how it would be dealt with internally would be different. I could be wrong on that though. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4694] New: Unused last assignment warning
http://d.puremagic.com/issues/show_bug.cgi?id=4694
Summary: Unused last assignment warning
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Keywords: diagnostic
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bearophile_h...@eml.cc
--- Comment #0 from bearophile_h...@eml.cc 2010-08-20 14:44:40 PDT ---
This enhancement request is about a warning that helps avoid some kinds of
bugs.
(This is related but distinct from the enhancement request of bug 3960
This has nothing to do with uninitialized variables, it's kind of the opposite
problem).
The "Unused last assignment warning" means that you assign something to a
variable, and then you do nothing with it.
The compiler is often able to remove the dead code, but the presence of this
situation may denote low quality code, or code where the programmer has
forgotten to use the variable. In both cases it's useful to find such
situations.
void main() {
int x;
x = 10; // warning here
}
Here 'x' is not an unused variable, because the code does something with it, so
there is no warning for unused variable (bug 3960 ), but this code deserves a
warning anyway because the last value assigned to x is not unused.
It is better to not show this warning if the variable address is assigned to a
pointer or similar things.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4693] New: std.range.iota fails with long type
http://d.puremagic.com/issues/show_bug.cgi?id=4693
Summary: std.range.iota fails with long type
Product: D
Version: D2
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: necrom...@gmail.com
--- Comment #0 from Max Klyga 2010-08-20 14:34:34 PDT ---
import std.range;
void main() {
iota(1, 2_147_483_648);
}
outputs:
src/phobos/std/range.d(2154): Error: cannot implicitly convert expression
(aBitAboveCount) of type long to uint
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4688] [patch] rdmd/Win: rdmd'ed program's output appears after cmd prompt
http://d.puremagic.com/issues/show_bug.cgi?id=4688 Nick Sabalausky changed: What|Removed |Added Attachment #732 is|0 |1 obsolete|| --- Comment #2 from Nick Sabalausky 2010-08-20 14:10:24 PDT --- Created an attachment (id=734) Fixed patch against rdmd r1400 Fixed an issue with the patch, too many backslashes were being escaped. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4692] New: Cyclic import breaks is() in a static if in a struct
http://d.puremagic.com/issues/show_bug.cgi?id=4692
Summary: Cyclic import breaks is() in a static if in a struct
Product: D
Version: D1
Platform: x86
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nyphb...@gmail.com
--- Comment #0 from William Moore 2010-08-20 14:10:04 PDT
---
Compilation fails with:
breaker.d(11): Error: identifier 'r' is not defined
breaker.d(7): Error: template instance breaker.ElemType!() error instantiating
given the following for breaker.d:
module breaker;
import breaker;
void main(){}
struct Test {
static if (is(ElemType!())) {}
}
template ElemType() {
alias r ElemType;
}
Note that when you remove "import breaker;", the code compiles without error.
This was distilled from a 4 module circular import.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4673] Bug in std.string (isNumeric)
http://d.puremagic.com/issues/show_bug.cgi?id=4673
--- Comment #6 from kenn...@gmail.com 2010-08-20 14:13:56 PDT ---
Should complex literals ("3.4+5.6i") _still_ be considered numeric? As the
built-in complex types are scheduled for deprecation...
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4673] Bug in std.string (isNumeric)
http://d.puremagic.com/issues/show_bug.cgi?id=4673 --- Comment #5 from Petit Vincent 2010-08-20 23:06:05 CEST --- Created an attachment (id=733) Maybe a patch which works. Well this is way to improve the current isNumeric function. It works well for these kinds of numerics : (+/-) 1, 1L, 1UL, 1i, 1Fi, 1Li, 1F 1.55 1e+52 1_500_250 nan, nani, nan+nani (+/-) inf At least, this patch correct bugs found in the std.isNumeric function. Sure we can (should !) improve it but at least it works (except for numerics like .5e-52 but 0.5e-52 works) -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4691] Incorrect comparison of double and long
http://d.puremagic.com/issues/show_bug.cgi?id=4691
bearophile_h...@eml.cc changed:
What|Removed |Added
CC||bearophile_h...@eml.cc
--- Comment #1 from bearophile_h...@eml.cc 2010-08-20 13:06:56 PDT ---
Reduced test case:
double d = 1.5;
long l = 1;
void main() {
assert(d >= l);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4691] New: Incorrect comparison of double and long
http://d.puremagic.com/issues/show_bug.cgi?id=4691
Summary: Incorrect comparison of double and long
Product: D
Version: D1 & D2
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bugzi...@digitalmars.com
--- Comment #0 from Walter Bright 2010-08-20
12:15:45 PDT ---
import std.c.stdio;
struct UN
{
double dd;
long ll;
}
string cmp( UN * pU )
{
return pU.dd >= pU.ll ? "OK" : "ERRROR";
}
int main()
{
static UN u = { 10.50, 10 };
printf( "%.*s\n", cmp( &u ) );
return 0;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3960] Unused variable warning
http://d.puremagic.com/issues/show_bug.cgi?id=3960 Jonathan M Davis changed: What|Removed |Added CC||jmdavisp...@gmail.com --- Comment #3 from Jonathan M Davis 2010-08-20 09:54:44 PDT --- Okay. Giving a warning for an unused variable makes sense. However, giving a warning for setting it somewhere that is not where it is declared doesn't make sense. Sure, in this case, it's dumb of the programmer to have done that, but 1. The compiler should be able to optimize out such a simple case. 2. More complex cases much harder to detect, and it's not all that hard for you to _want_ to disconnect the declaration of the variable and initializing it - likely because of scoping issues or conditional blocks. The compiler is only going to be able to detect the simplest cases, and as I said in #1, such simple cases will likely get optimized away. Cases too complex to optimize away are going to be much harder for the compiler to detect, and if you start going that far, you're getting to the point where you just about should have done what Java did and force initialization of variables rather than default initialize them. Not initializing a variable yourself, and the setting it later with a value that you could have set it to at its declaration is not a coding error. It may not be best practice, but it's not going to result in an error. So, I don't think that it makes any sense to make it a warning. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3960] Unused variable warning
http://d.puremagic.com/issues/show_bug.cgi?id=3960
--- Comment #2 from bearophile_h...@eml.cc 2010-08-20 09:04:27 PDT ---
There is more than just unused variables, there are also unused last
assignments:
void main() {
int x;
x = 10;
}
Here 'x' is not an unused variable, because the code does something with it,
but the code deserves a warning anyway (and one C compiler-like shows this
warning) because the last value assigned to it gets unused; and this is wasted
coding/running effort at best, or sign of a possible latent bug (just like
unused variables).
This warning isn't necessary if the variable address is assigned to a pointer
or similar things.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 314] [module] Static, renamed, and selective imports are always public
http://d.puremagic.com/issues/show_bug.cgi?id=314
--- Comment #28 from Christian Kamm
2010-08-20 07:48:05 PDT ---
> But if you can write the
> essence of the code here, which I think is really only a couple of functions,
> that should be enough.
AliasDeclaration and FuncAliasDeclaration get a new 'importprot' member which
is set for aliases generated by the import declaration and stores the import's
protection.
In ScopeDSymbol::search, we discard aliases which shouldn't be accessible -
unless it's a FuncAliasDeclaration, to avoid making a chain invisible because
the first member is privately imported:
+// hide the aliases generated by selective or renamed private imports
+if (s && flags & 1)
+if (AliasDeclaration* ad = s->isAliasDeclaration())
+// may be a private alias to a function that is overloaded. these
+// are sorted out during overload resolution, accept them here
+if (ad->importprot == PROTprivate &&
!ad->aliassym->isFuncAliasDeclaration())
+s = NULL;
And for overload resolution, skip over functions that should be invisible:
-int overloadApply(FuncDeclaration *fstart,
+int overloadApply(Module* from, FuncDeclaration *fstart,
int (*fp)(void *, FuncDeclaration *),
void *param)
...
if (fa)
{
-if (overloadApply(fa->funcalias, fp, param))
-return 1;
+if (fa->getModule() == from || fa->importprot != PROTprivate)
+if (overloadApply(from, fa->funcalias, fp, param))
+return 1;
next = fa->overnext;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4690] New: ref return should allow assignment if not overridden
http://d.puremagic.com/issues/show_bug.cgi?id=4690
Summary: ref return should allow assignment if not overridden
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: dsim...@yahoo.com
--- Comment #0 from David Simcha 2010-08-20 06:39:19 PDT ---
struct Foo {
uint num;
@property ref uint front() {
return num;
}
ref uint opIndex(size_t index) {
return num;
}
}
void main() {
Foo foo;
foo.front++; // Works
foo.front += 1;// error 1
foo.front = 1; // error 2
foo[0] = 1;// error 3
}
If something returns by reference then it should be usable for assignment,
though if the class/struct contains an explicit setter property or
opIndexAssign, this should override assignment via ref return. Here are the
error messages produced.
test9.d(16): Error: 'foo.front' is not a scalar, it is a @property ref uint()
test9.d(16): Error: incompatible types for ((foo.front) += (1)): '@property ref
uint()' and 'int'
test9.d(17): Error: function test9.Foo.front () is not callable using argument
types (int)
test9.d(17): Error: expected 0 arguments, not 1 for non-variadic function type
@property ref uint()
test9.d(18): Error: operator [] assignment overload with opIndex(i, value)
illegal, use opIndexAssign(value, i)
I'm aware that other bugs have reported bits and pieces of this problem, but I
think this is a clearer bug report on the more general issue. Also, marking as
major because it's a significant impedement to library development in
std.range.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4685] in contract of base class affected by the body of the overriding function
http://d.puremagic.com/issues/show_bug.cgi?id=4685 Stewart Gordon changed: What|Removed |Added Keywords||wrong-code CC||s...@iname.com Version|D2 |D1 & D2 --- Comment #1 from Stewart Gordon 2010-08-20 06:32:34 PDT --- Under DMD 1.063, it fails as written as writeln isn't defined, but if changed to writefln I get in basicdate.format contract xin date.format contract 1234 Under 2.048, I get the same, but if I change it to use writefln then I get in basicdate.format contract in date.format contract 1234 -- 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 Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #3 from Rainer Schuetze 2010-08-20 05:31:37 PDT --- Fixed in 2.047 together with bug 3200 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4603] array(iota(1, 0)) error
http://d.puremagic.com/issues/show_bug.cgi?id=4603 bearophile_h...@eml.cc changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #7 from bearophile_h...@eml.cc 2010-08-20 05:16:23 PDT --- Thank you for improving this bug. But I reopen the bug because I think raising an error is the wrong design. As I have explained iota() is to be meant as the ranges in for/foreach loops, so iota(1, 0) is like an empty loop, it's not an error. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4655] Regression(1.063, 2.048) goto to a try block ICEs
http://d.puremagic.com/issues/show_bug.cgi?id=4655 Don changed: What|Removed |Added Keywords||patch --- Comment #2 from Don 2010-08-20 03:35:55 PDT --- Silly mistake in the implementation of forward references, in the patch for 4339. It remembers the block the label is in, when it should be recording the block which it was referenced from. PATCH: s2ir.c, line 107, labelToBlock() // Keep track of the forward reference to this block, so we can check it later if (!s->fwdrefs) s->fwdrefs = new Array(); -s->fwdrefs->push(s->lblock); +s->fwdrefs->push(blx->curblock); } } return s->lblock; -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4689] New: Error: cast from const(int) to real not allowed in safe code
http://d.puremagic.com/issues/show_bug.cgi?id=4689
Summary: Error: cast from const(int) to real not allowed in
safe code
Product: D
Version: D2
Platform: Other
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: zan77...@nifty.com
--- Comment #0 from SHOO 2010-08-20 02:45:43 PDT ---
This code should be compiled:
struct S{
int x;
@safe const real getX(){ return cast(real)x; }
}
Error: cast from const(int) to real not allowed in safe code
See also: http://lists.puremagic.com/pipermail/phobos/2010-August/001958.html
(2010/08/20 0:08), Andrei Alexandrescu wrote:
>>> Line 414: no need for @trusted, casting numbers is not unsafe.
>>>
>>
>> Error: cast from const(long) to real not allowed in safe code
>
>Compiler bug. I wonder whether const has anything to do with (shouldn't).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 4688] [patch] rdmd/Win: rdmd'ed program's output appears after cmd prompt
http://d.puremagic.com/issues/show_bug.cgi?id=4688 --- Comment #1 from Nick Sabalausky 2010-08-20 00:30:21 PDT --- Note: The patch also fixes a minor issue where rdmd imports the "scheduled for deprecation" std.contracts instead of the (apparently) preferred std.exception. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 4688] New: [patch] rdmd/Win: rdmd'ed program's output appears after cmd prompt
http://d.puremagic.com/issues/show_bug.cgi?id=4688 Summary: [patch] rdmd/Win: rdmd'ed program's output appears after cmd prompt Product: D Version: D2 Platform: Other OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: nob...@puremagic.com ReportedBy: cbkbbej...@mailinator.com --- Comment #0 from Nick Sabalausky 2010-08-20 00:26:09 PDT --- Created an attachment (id=732) Patch against rdmd r1400 On Windows (XP Pro SP2 32-bit, not sure about other versions): Expected: C:\myDir>rdmd helloworld.d Hello, world! C:\myDir> Actual: C:\myDir>rdmd helloworld.d C:\myDir>Hello, world! This happens because execv fools the Windows command-line into thinking the program is done and returning control back to the user. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
