[Issue 2874] New: phobos docs issues
http://d.puremagic.com/issues/show_bug.cgi?id=2874 Summary: phobos docs issues Product: D Version: 2.029 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: bugzi...@digitalmars.com ReportedBy: samu...@voliacable.com http://www.digitalmars.com/d/2.0/phobos/std_range.html: instances of the popFront need to be corrected to the next. On the std.algorithm page, the examples for map and filter don't compile due to the fixed size array in equal(). The example for bringToFront is outdated. The comments for remove: If $(s = - If $(D s = --
[Issue 2875] New: ICE(cgcod.c) setting delegate = Struct.func
http://d.puremagic.com/issues/show_bug.cgi?id=2875
Summary: ICE(cgcod.c) setting delegate = Struct.func
Product: D
Version: 2.029
Platform: PC
OS/Version: Windows
Status: NEW
Keywords: ice-on-invalid-code, wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: clugd...@yahoo.com.au
struct Foo {
void foo(int x) {}
}
void main() {
void delegate (int) a = Foo.foo;
}
Internal error: ..\ztc\cgcod.c 1549
Possibly related to bug 1709: it silently compiles wrong code when compiled
with -O. D2 only; D1.042 is OK.
--
[Issue 2339] Inconsistent behaviour referring to template mixin member at compile time
http://d.puremagic.com/issues/show_bug.cgi?id=2339
--- Comment #1 from matti.niemenmaa+dbugzi...@iki.fi 2009-04-22 03:51
---
I've been investigating this a bit and the issue seems to be that
VarDeclaration::needThis() returns true for x; if I make it return false
instead, the code compiles fine. Unfortunately, I can't think of a test that
would cause that and related cases to return false without breaking something
else.
Alternatively, needThis() is correct but some places should be checking for
something else as well.
Here's another testcase, in case it's any help. In this one, it's
FuncDeclaration::needThis() that we don't want returning true.
template ReturnTypeOf(alias f) {
alias typeof(f()) ReturnTypeOf;
}
template FooIn(char[] s) {
mixin (
`template Run() {
const Run =
static if (is(ReturnTypeOf!(mixin(\`~s~`.foo\)) == void))
`~s~`.foo;
else
static assert (false);
;
}`
);
}
template Mixin() { void foo() { throw new Exception(Success!); } }
class C {
mixin Mixin!() M;
void runFoo() {
// Works
static assert (is(ReturnTypeOf!(M.foo) == void));
// Fails
// static assert (is(ReturnTypeOf!(mixin(M.foo)) == void));
// Fails at an incorrect line number
// mixin (FooIn!(M).Run!());
// Fails like the 2nd case above
// static if (is(ReturnTypeOf!(mixin(M.foo)) == void))
//M.foo;
// else
//static assert (false);
}
}
void main() { (new C).runFoo(); }
I tried returning false from needThis() if scope-parent-isTemplateMixin(),
but that breaks code like this (an LDC testcase):
extern(C) int printf(char*, ...);
template Foo() { void test() { printf(test\n); typeof(this).whee(); } }
class Bar { void whee() { printf(whee\n); } mixin Foo!(); }
void main() { (new Bar).test(); }
--
[Issue 302] in/out contract inheritance yet to be implemented
http://d.puremagic.com/issues/show_bug.cgi?id=302 --- Comment #2 from s...@iname.com 2009-04-22 06:46 --- it's not bad code generation - how do you work that out? --
[Issue 302] in/out contract inheritance yet to be implemented
http://d.puremagic.com/issues/show_bug.cgi?id=302 --- Comment #3 from clugd...@yahoo.com.au 2009-04-22 07:34 --- (In reply to comment #2) it's not bad code generation - how do you work that out? Bad code generation generally means the front-end is sending incorrect data to the backend; or else there's a bug in the backend. (Also for the case of CTFE, it can also include bugs in the interpreter; in that case, the frontend is the backend). In this case, the bug is really in the spec: the spec states a vague intention about how contracts should work, but there's never been any attempt whatsoever to implement it in the compiler. At the very least, the spec should say that it's not implemented, and I suspect that it should be completely removed from the D1 spec, unless Walter actually intends to implement it in D1. I notice that these unimplemented things (array operations was the other obvious one, but I suspect there are others) all date from the very early days of D. In modern times, Walter's mostly changed the spec only when he's actually implemented something. --
[Issue 302] in/out contract inheritance yet to be implemented
http://d.puremagic.com/issues/show_bug.cgi?id=302 --- Comment #4 from fvbom...@wxs.nl 2009-04-22 07:41 --- The spec specifies what the code should do, but the code being generated does something else. How is that not the very definition of wrong-code? (This probably falls in the the front-end is sending incorrect data to the backend category) Never having been implemented doesn't change any of this, IMHO. --
[Issue 2876] suggest keyword:auto return
http://d.puremagic.com/issues/show_bug.cgi?id=2876 --- Comment #1 from fvbom...@wxs.nl 2009-04-22 07:56 --- *** Bug 2877 has been marked as a duplicate of this bug. *** --
[Issue 302] in/out contract inheritance yet to be implemented
http://d.puremagic.com/issues/show_bug.cgi?id=302 clugd...@yahoo.com.au changed: What|Removed |Added Keywords||spec --- Comment #5 from clugd...@yahoo.com.au 2009-04-22 08:25 --- (In reply to comment #4) The spec specifies what the code should do, but the code being generated does something else. How is that not the very definition of wrong-code? (This probably falls in the the front-end is sending incorrect data to the backend category) Never having been implemented doesn't change any of this, IMHO. I think the problem is in the spec in this case. When it's not implemented, it should either marked as not yet implemented in DMD, or it shouldn't be in the spec at all yet. _Every_ other case of wrong-code in bugzilla is different. The nature of the issue is completely different, so I really think it's unhelpful to use the same keyword for both. --
[Issue 302] in/out contract inheritance yet to be implemented
http://d.puremagic.com/issues/show_bug.cgi?id=302 --- Comment #6 from llu...@gmail.com 2009-04-22 08:35 --- (In reply to comment #5) (In reply to comment #4) The spec specifies what the code should do, but the code being generated does something else. How is that not the very definition of wrong-code? (This probably falls in the the front-end is sending incorrect data to the backend category) Never having been implemented doesn't change any of this, IMHO. I think the problem is in the spec in this case. When it's not implemented, it should either marked as not yet implemented in DMD, or it shouldn't be in the spec at all yet. _Every_ other case of wrong-code in bugzilla is different. The nature of the issue is completely different, so I really think it's unhelpful to use the same keyword for both. I don't think is a good idea to change the specs according to DMD. DMD is just an implementation, an incomplete one. It's not serious to change an spec because an implementation don't implement a feature! I don't know if this is wrong-code or not, but I know it's not a spec issue, is a missing feature in DMD. So please, please, please, don't change the specs, fix the implementation. Thanks! --
[Issue 2878] New: Forward reference
http://d.puremagic.com/issues/show_bug.cgi?id=2878
Summary: Forward reference
Product: D
Version: 1.042
Platform: PC
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: ben...@tionex.de
compile with dmd M N
=== M.d === Start
module M;
import N;
abstract class Format{
static class Field {}
abstract void doit( FieldPosition p );
}
void main(){}
=== M.d === End
=== N.d === Start
module N;
import M;
class FieldPosition {
static class F2 : M.Format.Field {
}
this( M.Format.Field f){
}
}
=== N.d === End
Messages:
M.d(3): Error: class M.Format is forward referenced when looking for 'Field'
M.d(3): Error: class M.Format is forward referenced when looking for 'Field'
M.d(3): Error: class M.Format is forward referenced when looking for 'Field'
N.d(6): Error: no property 'Field' for type 'M.Format'
N.d(6): Error: M.Format.Field is used as a type
N.d(6): Error: class N.FieldPosition.F2 base type must be class or interface,
not void
M.d(3): Error: class M.Format is forward referenced when looking for 'Field'
M.d(3): Error: class M.Format is forward referenced when looking for 'Field'
M.d(3): Error: class M.Format is forward referenced when looking for 'Field'
N.d(8): Error: no property 'Field' for type 'M.Format'
N.d(8): Error: M.Format.Field is used as a type
N.d(8): Error: cannot have parameter of type void
--
[Issue 302] in/out contract inheritance yet to be implemented
http://d.puremagic.com/issues/show_bug.cgi?id=302 --- Comment #7 from s...@iname.com 2009-04-22 09:53 --- (In reply to comment #6) So please, please, please, don't change the specs, fix the implementation. I entirely agree. Moreover, I proposed a strategy more than 3 years ago. So why is it taking so long? --
[Issue 1929] concatenation of multi-dimensional arrays fails when holding static arrays
http://d.puremagic.com/issues/show_bug.cgi?id=1929 --- Comment #1 from clugd...@yahoo.com.au 2009-04-22 10:04 --- Works for me D2.029 and 1.042. --
[Issue 2879] New: std.bigint missing from phobos
http://d.puremagic.com/issues/show_bug.cgi?id=2879 Summary: std.bigint missing from phobos Product: D Version: 2.029 Platform: PC OS/Version: Windows Status: NEW Severity: normal Priority: P2 Component: Phobos AssignedTo: bugzi...@digitalmars.com ReportedBy: paul.d.ander...@boeing.com The std.bigint package is missing from the updated phobos distribution --
[Issue 2880] New: DMD is generating the wrong file line number for a (new) phobos error in conv.text. traits.d:1011 conv.d:2454
http://d.puremagic.com/issues/show_bug.cgi?id=2880 Summary: DMD is generating the wrong file line number for a (new) phobos error in conv.text. traits.d:1011 conv.d:2454 Product: D Version: 2.029 Platform: PC OS/Version: Windows Status: NEW Keywords: diagnostic Severity: normal Priority: P3 Component: DMD AssignedTo: bugzi...@digitalmars.com ReportedBy: sandf...@jhu.edu // test case immutable foo = 4; // immutable uint foo = 4; // Fixes the error auto t = std.conv.text(foo); // Error // DMD output C:\dmd\src\phobos\std\traits.d:1011: Error: static assert Type immutable(int) does not have an Unsigned counterpart C:\dmd\src\phobos\std\traits.d:2454: Error: template instance std.traits.Unsigned!(immutable(int)) error instantiating C:\dmd\src\phobos\std\conv.d:2454: Error: Unsigned!(immutable(int)) is used as a type Note that traits.d only has 1148 lines. Also, the trace does not contain enough information to track down the problem (i.e. only functions in phobos are reported) --
[Issue 2807] Marking a nested function as 'pure' may cause bad code generations silently accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2807
--- Comment #1 from clugd...@yahoo.com.au 2009-04-22 15:07 ---
And here's a patch. This makes it safe to have nested pure functions.
A nested pure function is only permitted to access its own variables, plus
immutables and manifest constants from outer scopes.
===
--- expression.c(revision 24)
+++ expression.c(working copy)
@@ -3994,12 +3994,21 @@
#if 1
if (sc-func) {
FuncDeclaration *outerfunc=sc-func;
+ bool hasPureParent=false;
while (outerfunc-toParent2()
outerfunc-toParent2()-isFuncDeclaration()) {
+ hasPureParent |= outerfunc-isPure();
outerfunc =
outerfunc-toParent2()-isFuncDeclaration();
}
-if (outerfunc-isPure() !sc-intypeof v-isDataseg()
!v-isInvariant())
+ hasPureParent |= outerfunc-isPure();
+ // If ANY of its enclosing functions are pure, it cannot do
anything impure.
+ // If it is pure, it cannot access any mutable variables other
than those inside itself.
+ if (hasPureParent !sc-intypeof v-isDataseg()
!v-isInvariant()) {
error(pure function '%s' cannot access mutable static data
'%s', sc-func-toChars(), v-toChars());
- }
+ } else if (sc-func-isPure() sc-parent!=v-parent !sc-intypeof
!v-isInvariant() !(v-storage_class STCmanifest)) {
+ error(pure nested function '%s' cannot access mutable
data '%s', sc-func-toChars(), v-toChars());
+ if (v-isEnumDeclaration()) error(enum);
+ }
+ }
#else
if (sc-func sc-func-isPure() !sc-intypeof)
{
--
[Issue 2807] Marking a nested function as 'pure' may cause bad code generations silently accepted
http://d.puremagic.com/issues/show_bug.cgi?id=2807 --- Comment #2 from clugd...@yahoo.com.au 2009-04-22 15:09 --- Created an attachment (id=335) -- (http://d.puremagic.com/issues/attachment.cgi?id=335action=view) Patch against 2.029. Includes patch for the related bug 2695, as well. --
[Issue 2881] New: x.stringof returns typeof(x).stringof when x is an enum
http://d.puremagic.com/issues/show_bug.cgi?id=2881
Summary: x.stringof returns typeof(x).stringof when x is an enum
Product: D
Version: 1.041
Platform: PC
OS/Version: Windows
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: cbkbbej...@mailinator.com
-
enum Shapes
{
Circle, Square
}
void main()
{
int i;
Shapes s;
pragma(msg, i.stringof);
pragma(msg, s.stringof);
}
-
Expected Output:
i
s
Actual Output:
i
Shapes
I'm not sure, but this might be related to the fix for #1610
--
[Issue 2882] New: std.random.MersenneTwisterEngine without no seed
http://d.puremagic.com/issues/show_bug.cgi?id=2882
Summary: std.random.MersenneTwisterEngine without no seed
Product: D
Version: 2.029
Platform: PC
OS/Version: Windows
Status: NEW
Severity: minor
Priority: P4
Component: Phobos
AssignedTo: bugzi...@digitalmars.com
ReportedBy: repeate...@gmail.com
void main()
{
writeln(Case1);
{
Mt19937 gen = Mt19937(0);
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln(---);
{
Mt19937 gen = Mt19937(0);
advance(gen, 1); // skip 1 element
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln(Â¥nCase2);
{
Mt19937 gen;
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
writeln(---);
{
Mt19937 gen;
advance(gen, 1); // skip 1 element
writeln(gen.front);
gen.popFront;
writeln(gen.front);
}
}
Result:
Case1
2357136044 (1)
2546248239 (2)
---
2546248239 (2)
3071714933 (3)
Case2
581869302 (1)
3890346734 (2)
---
581869302 (1)?
3890346734 (2)?
The second part of Case2 skipped one element using advance(calling popFront),
but the result didn't skip.
--
[Issue 2878] Forward reference error with circular import and nested classes
http://d.puremagic.com/issues/show_bug.cgi?id=2878 s...@iname.com changed: What|Removed |Added CC||s...@iname.com OtherBugsDependingO||340 nThis|| Keywords||rejects-valid Summary|Forward reference |Forward reference error with ||circular import and nested ||classes --- Comment #1 from s...@iname.com 2009-04-22 20:17 --- This could be related to bug 102. Except that this one compiles without error if N is given on the command line first. --
[Issue 1432] Bogus overlapping initialization error with structs, unions, and member initializers
http://d.puremagic.com/issues/show_bug.cgi?id=1432
--- Comment #1 from to...@famolsen.dk 2009-04-22 21:33 ---
Another variation:
union S
{
float[2] a;
struct
{
union { float i = 1; float x; }
union { float j = 2; float y; }
}
}
$ dmd bar.d -c
bar.d(2): Error: union bar.S overlapping initialization for struct S.i
bar.d(2): Error: union bar.S overlapping initialization for struct S.j
If 'a' is moved below the anonymous struct it works. The spec does not mention
this special case as far as I can tell. Explicit initialization of aggregate
fields inside anonymous struct/union combinations should be documented.
--
[Issue 2883] New: array member call syntax fails when array is returned from property syntax
http://d.puremagic.com/issues/show_bug.cgi?id=2883
Summary: array member call syntax fails when array is returned
from property syntax
Product: D
Version: 1.041
Platform: PC
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: bugzi...@digitalmars.com
ReportedBy: cbkbbej...@mailinator.com
When you want to use the myArray.myFuncTakingAnArray() syntax on an array
that's returned from a function, it fails to compile if the array-returning
function is called using getArray instead of getArray().
-
char[] getArray()
{ return hello; }
void useArray(char[] str)
{ /* stuff */ }
void main()
{
int i;
i = getArray().length; // Ok
i = getArray.length; // Ok
getArray().useArray(); // Ok
getArray.useArray(); // Error: no property 'useArray' for type
'char[]'
}
-
--
