[Issue 3910] New: Explicit template instantiations for functions used as array properties?
http://d.puremagic.com/issues/show_bug.cgi?id=3910
Summary: Explicit template instantiations for functions used as
array properties?
Product: D
Version: 2.041
Platform: Other
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bio...@free.fr
--- Comment #0 from biozic bio...@free.fr 2010-03-09 00:40:11 PST ---
Shouldn't the last line of the following code compile?
---
void foo(T)(T[] array) {}
void main()
{
int[] a = [1, 2, 3];
foo(a); // OK
foo!int(a); // OK
a.foo(); // OK
//a.foo!int(); // Error: foo(a) isn't a template
}
---
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3901] PATCH: Nested struct assignment for CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=3901 --- Comment #3 from Don clugd...@yahoo.com.au 2010-03-09 01:57:49 PST --- (In reply to comment #2) Thank you for all such big work. New features: ... * ref return values now work in CTFE (D2 only). So is this fixing bug 2411 too? Unfortunately not. This fixes the 'ref' part of the problem, but bug 1330 still prevents it from working. Bug 1330 is actually the fundamental CTFE problem: once it is fixed, almost everything will work. This patch cleans everything up so that there's a chance of fixing 1330. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3792] Regression: non-constant expression for a template inside a struct using a struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=3792 Fawzi Mohamed fa...@gmx.ch changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #5 from Fawzi Mohamed fa...@gmx.ch 2010-03-09 03:24:39 PST --- As I wrote in my previous comment, the attached testcase still fails... -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1807] ENHANCEMENT: Let IFTI see through templates to simple aliases
http://d.puremagic.com/issues/show_bug.cgi?id=1807 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added CC||bearophile_h...@eml.cc --- Comment #4 from Steven Schveighoffer schvei...@yahoo.com 2010-03-09 04:15:46 PST --- *** Issue 3904 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 3904] Infer function type from an alias in a template
http://d.puremagic.com/issues/show_bug.cgi?id=3904 Steven Schveighoffer schvei...@yahoo.com changed: What|Removed |Added Status|NEW |RESOLVED CC||schvei...@yahoo.com Resolution||DUPLICATE --- Comment #1 from Steven Schveighoffer schvei...@yahoo.com 2010-03-09 04:15:46 PST --- *** This issue has been marked as a duplicate of issue 1807 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3912] New: pure static nested functions are not recognized as pure
http://d.puremagic.com/issues/show_bug.cgi?id=3912
Summary: pure static nested functions are not recognized as
pure
Product: D
Version: 2.040
Platform: Other
OS/Version: Windows
Status: NEW
Keywords: rejects-valid
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: clugd...@yahoo.com.au
--- Comment #0 from Don clugd...@yahoo.com.au 2010-03-09 04:29:59 PST ---
This bug was reported in a comment in bug 3835 (fragile CTFE), but it does
not involve CTFE, so I've created a new bug for it.
=
pure int genFactorials(int n) {
static pure int factorial(int n) {
if (n==2) return 1;
return factorial(2);
}
return factorial(n);
}
bug.d(7): Error: pure function 'factorial' cannot call impure function 'factor
ial'
bug.d(9): Error: pure function 'genFactorials' cannot call impure function 'fa
ctorial'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3911] New: Associative array in CTFE crashes compiler
http://d.puremagic.com/issues/show_bug.cgi?id=3911
Summary: Associative array in CTFE crashes compiler
Product: D
Version: 2.041
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-03-09 02:26:43 PST ---
This crashes the compiler:
auto bunch(T)(T[] items...) {
return [+ : 0];
}
enum int* r = + in bunch(1);
void main() {}
The following variant of the same program doesn't crash the compiler, but gives
a forward reference error, that seems wrong:
Error: forward reference to bunch
auto bunch() {
return [+ : 0];
}
enum int* r = + in bunch();
void main() {}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3835] [CTFE] Fragile CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=3835 --- Comment #6 from Don clugd...@yahoo.com.au 2010-03-09 04:32:40 PST --- I created bug 3912 for the third bug mentioned in the comments, which has nothing to do with CTFE. Maybe this bug can now be marked as a duplicate of bug 2411? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3835] [CTFE] Fragile CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=3835 --- Comment #7 from bearophile_h...@eml.cc 2010-03-09 04:45:06 PST --- You can mark this as duplicate. But when an improvement is created, it's necessary to try it with *all* duplicated examples too, because you must be sure they are really problems with the same cause. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3914] New: Struct as argument that fits in register has member accessed wrong
http://d.puremagic.com/issues/show_bug.cgi?id=3914
Summary: Struct as argument that fits in register has member
accessed wrong
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: crimson.ma...@gmail.com
--- Comment #0 from Aldo Nunez crimson.ma...@gmail.com 2010-03-09 10:54:31
PST ---
Depending on the build options and where in a function the struct parameter is
used, referencing one member will actually reference another one.
Given the following program:
import std.stdio;
struct SS
{
char a;
char b;
char c;
char d;
//char e;
}
void A( SS ss1 )
{
C://writeln( ss1.a, ss1.b, ss1.c, ss1.d );
char temp;
temp = ss1.a;
ss1.a = ss1.d;
ss1.d = temp;
temp = ss1.b;
ss1.b = ss1.c;
ss1.c = temp;
B://writeln( ss1.a, ss1.b, ss1.c, ss1.d );
temp = ss1.a;
ss1.a = ss1.d;
ss1.d = temp;
temp = ss1.b;
ss1.b = ss1.c;
ss1.c = temp;
A:writeln( ss1.a, ss1.b, ss1.c, ss1.d );
}
void main()
{
SS ss3;
ss3.a = 'A';
ss3.b = 'L';
ss3.c = 'D';
ss3.d = 'O';
A( ss3 );
}
If lines A, B, and C are enabled in the following pattern along with the given
build options, you get these results:
(none)-g-rel-rel-O-O-g -O
AALDOALDOALDOALDAALDAALDA
B, AODLAODLAODLAADLAADLAADLA
ALDOALDOALDOALDAALDAALDA
C, B, AALDAALDOALDAALDAALDAALDA
ODLAODLAODLAODLAODLAODLA
ALDOALDOALDOALDOALDOALDO
In particular, notice that field 'd' starts off wrong.
If I uncomment field 'e', or change one of them to an int, the problem goes
away.
At C, ALDO should be printed.
At B, ODLA should be printed.
At A, ALDO should be printed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3915] New: typeid not getting type of offsetof standard property
http://d.puremagic.com/issues/show_bug.cgi?id=3915
Summary: typeid not getting type of offsetof standard property
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: crimson.ma...@gmail.com
--- Comment #0 from Aldo Nunez crimson.ma...@gmail.com 2010-03-09 11:43:00
PST ---
The expressions typeid( SS.b.offsetof ) and typeid( ss3.b.offsetof ) fail with
the error no property 'offsetof' for type 'char'.
Using typeof in between makes them work, as in typeid( typeof( SS.b.offsetof )
). Changing offsetof to sizeof also works.
Here's the sample program:
import std.stdio;
struct SS
{
char a;
char b;
}
void main()
{
SS ss3;
ss3.a = 'A';
ss3.b = 'L';
writeln( SS.b.offsetof );
//writeln( typeid( SS.b.offsetof ) ); // error
writeln( ss3.b.offsetof );
//writeln( typeid( ss3.b.offsetof ) ); // error
writeln( typeid( typeof( SS.b.offsetof ) ) );
writeln( typeid( typeof( ss3.b.offsetof ) ) );
}
This problem looks related to bugs #3643 and 1684.
But this one is about not getting the type of the offsetof standard property.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3916] New: opEquals for objects does not respect const
http://d.puremagic.com/issues/show_bug.cgi?id=3916
Summary: opEquals for objects does not respect const
Product: D
Version: 2.041
Platform: Other
OS/Version: All
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2010-03-09
11:54:35 PST ---
Example:
class C
{
int x;
bool opEquals(Object d) {++x; return false;}
}
void main()
{
const c1= new C;
const c2= new C;
assert(c1 != c2);
assert(c1.x == 1);
}
This should fail to compile. I'm unsure what the correct signature for
opEquals should be, but I'd expect it to be something like:
bool opEquals(const Object other) const;
With the global function being changed to:
bool opEquals(const Object lhs, const Object rhs);
This may limit the ability to run cached calculations in the objects themselves
during comparisons, but I think this situation could be worked around with
casts.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3901] PATCH: Nested struct assignment for CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=3901 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2010-03-09 12:19:28 PST --- changeset 413 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3917] New: opEquals for Ojbect could be more efficient
http://d.puremagic.com/issues/show_bug.cgi?id=3917
Summary: opEquals for Ojbect could be more efficient
Product: D
Version: 2.041
Platform: Other
OS/Version: All
Status: NEW
Severity: enhancement
Priority: P2
Component: druntime
AssignedTo: s...@invisibleduck.org
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2010-03-09
12:42:34 PST ---
The implementation of opEquals in object_.d has an unnecessary recursive call.
The complete implementation is this:
bool opEquals(Object lhs, Object rhs)
{
// If aliased to the same object or both null = equal
if (lhs is rhs) return true;
// If either is null = non-equal
if (lhs is null || rhs is null) return false;
// If same exact type = one call to method opEquals
if (typeid(lhs) == typeid(rhs)) return lhs.opEquals(rhs);
// General case = symmetric calls to method opEquals
return lhs.opEquals(rhs) rhs.opEquals(lhs);
}
bool opEquals(TypeInfo lhs, TypeInfo rhs)
{
// If aliased to the same object or both null = equal
if (lhs is rhs) return true;
// If either is null = non-equal
if (lhs is null || rhs is null) return false;
// If same exact type = one call to method opEquals
if (typeid(lhs) == typeid(rhs)) return lhs.opEquals(rhs);
// Factor out top level const
// (This still isn't right, should follow same rules as compiler does for
type equality.)
TypeInfo_Const c = cast(TypeInfo_Const) lhs;
if (c)
lhs = c.base;
c = cast(TypeInfo_Const) rhs;
if (c)
rhs = c.base;
// General case = symmetric calls to method opEquals
return lhs.opEquals(rhs) rhs.opEquals(lhs);
}
The third if statement that compares two typeids recurses into opEquals for
typeinfos. In the typeinfo comparison, the typeinfos should never be null, and
the typeinfos of the typeinfo will always be identical (TypeInfo_Class). In
addition, the stuff at the end dealing with const will never come into play
because the dynamic typeinfo (the classinfo) never deals with const.
I'd propose to rewrite the opEquals as follows:
bool opEquals(Object lhs, Object rhs)
{
// If aliased to the same object or both null = equal
if (lhs is rhs) return true;
// If either is null = non-equal
if (lhs is null || rhs is null) return false;
// If same exact type = one call to method opEquals
if (typeid(lhs) is typeid(rhs) || typeid(lhs).opEquals(typeid(rhs))) return
lhs.opEquals(rhs);
// General case = symmetric calls to method opEquals
return lhs.opEquals(rhs) rhs.opEquals(lhs);
}
I don't know what else the opEquals that compares typeinfos is for, because
it's not a public function, so it could potentially be removed.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3581] private attribute breaks override
http://d.puremagic.com/issues/show_bug.cgi?id=3581
Vladimir thecybersha...@gmail.com changed:
What|Removed |Added
CC||thecybersha...@gmail.com
--- Comment #1 from Vladimir thecybersha...@gmail.com 2010-03-09 14:33:06 PST
---
Simpler test case:
class C
{
private override void f() {}
}
This code should not compile.
Removing private produces the expected function test.C.f does not override
any function error.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3918] New: Parameter use before its use in an AndAnd expression with reals treats NaN as false
http://d.puremagic.com/issues/show_bug.cgi?id=3918
Summary: Parameter use before its use in an AndAnd expression
with reals treats NaN as false
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: crimson.ma...@gmail.com
--- Comment #0 from Aldo Nunez crimson.ma...@gmail.com 2010-03-09 16:41:26
PST ---
NaN is supposed to be treated as true when implicitly converted to bool,
because it's not the same as zero. But, in the following case, the NaN is
treated as false.
- optimized build
- a variable of type real with value NaN
- the variable is used in an AndAnd () or OrOr (||) expression
- the variable is used before the AndAnd () or OrOr (||) expression
I assume this happens anywhere a real is turned into a bool, but I haven't
checked.
Here's a sample program:
import std.stdio;
void Do( float t, real u )
{
writeln( u );
writeln( t u );
}
void Do2( real t, float u )
{
writeln( t );
writeln( t u );
}
void main( string[] args )
{
Do( float.nan, real.nan );
Do2( real.nan, float.nan );
}
In the function calls to both Do and Do2, the result is false. It should be
true. Commenting out writeln( u ) and writeln( t ) also make the results
true.
Looking at the assembly code, I noticed that the cause seems to be an
instruction that's left out when the program is optimized.
Unoptimized (right):
00403C0D fld tbyte ptr [esp+8]
00403C11 fldz
00403C13 fucompp
00403C15 fnstsw ax
00403C17 sahf
00403C18 jne 00403C20
00403C1A jp 00403C20
Optimized (wrong):
00403C1E fld tbyte ptr [esp+8]
00403C22 fldz
00403C24 fucompp
00403C26 fnstsw ax
00403C28 sahf
00403C29 jne 00403C2F
The JP instruction is missing. As a result, we'll fall thru to where EAX is
cleared, and the result turns into false.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3667] Regression(D2 only): broken out(result) in contracts
http://d.puremagic.com/issues/show_bug.cgi?id=3667 Witold Baryluk bary...@smp.if.uj.edu.pl changed: What|Removed |Added CC||bary...@smp.if.uj.edu.pl --- Comment #3 from Witold Baryluk bary...@smp.if.uj.edu.pl 2010-03-09 17:08:03 PST --- It is probably related to bug3634 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3919] New: Assertion failure: '0' on line 9944 in file 'expression.c'
http://d.puremagic.com/issues/show_bug.cgi?id=3919
Summary: Assertion failure: '0' on line 9944 in file
'expression.c'
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: crimson.ma...@gmail.com
--- Comment #0 from Aldo Nunez crimson.ma...@gmail.com 2010-03-09 18:01:17
PST ---
The error is in MulExp::semantic. It happens no matter if the multiplication
expression is in a template. These are the combinations that fail:
IF * ifloat
IF * IF
ID * idouble
ID * ID
IR * ireal
IR * IR
Here's a sample:
import std.stdio;
typedef ifloat IF;
typedef idouble ID;
typedef ireal IR;
template PrintAddedType(X, Y)
{
void PrintAddedType()
{
X x;
Y y;
writeln( typeid( x ), , typeid( y ), , typeid( x * y ) );
}
}
template PrintAddedType(X)
{
void PrintAddedType()
{
/*
PrintAddedType!(X, ifloat)();
PrintAddedType!(X, idouble)();
PrintAddedType!(X, ireal)();
*/
/*
PrintAddedType!(X, IF)();
PrintAddedType!(X, ID)();
PrintAddedType!(X, IR)();
*/
}
}
void main()
{
/*
PrintAddedType!(IF)();
PrintAddedType!(ID)();
PrintAddedType!(IR)();
*/
IR x;
IR y;
writeln( typeid( x ), \t, typeid( y ), \t, typeid( x * y ) );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3920] New: Assertion failure: '0' on line 10018 in file 'expression.c'
http://d.puremagic.com/issues/show_bug.cgi?id=3920
Summary: Assertion failure: '0' on line 10018 in file
'expression.c'
Product: D
Version: 2.041
Platform: x86
OS/Version: Windows
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: crimson.ma...@gmail.com
--- Comment #0 from Aldo Nunez crimson.ma...@gmail.com 2010-03-09 18:03:42
PST ---
The error is in MulExp::semantic. It happens no matter if the multiplication
expression is in a template. These are the combinations that fail:
IF / ifloat
IF / IF
ID / idouble
ID / ID
IR / ireal
IR / IR
Here's a sample:
import std.stdio;
typedef ifloat IF;
typedef idouble ID;
typedef ireal IR;
template PrintAddedType(X, Y)
{
void PrintAddedType()
{
X x;
Y y;
writeln( typeid( x ), , typeid( y ), , typeid( x / y ) );
}
}
template PrintAddedType(X)
{
void PrintAddedType()
{
/*
PrintAddedType!(X, ifloat)();
PrintAddedType!(X, idouble)();
PrintAddedType!(X, ireal)();
*/
/*
PrintAddedType!(X, IF)();
PrintAddedType!(X, ID)();
PrintAddedType!(X, IR)();
*/
}
}
void main()
{
/*
PrintAddedType!(IF)();
PrintAddedType!(ID)();
PrintAddedType!(IR)();
*/
IR x;
IR y;
writeln( typeid( x ), , typeid( y ), , typeid( x / y ) );
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3342] TLS on dynamically loaded DLLs fails on Windows earlier than Vista
http://d.puremagic.com/issues/show_bug.cgi?id=3342 --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2010-03-09 23:11:09 PST --- I've been looking at the patch, it's an impressive piece of work! But I'd like it to detect the Windows version, and not do anything if it is Vista or newer, as those systems don't have the TLS bug. If we don't do this check, since the patch relies on undocumented ntdll internals, D apps are vulnerable to breaking with Windows updates. Also, skywing has some code to deal with this at http://www.nynaeve.net/Code/VistaImplicitTls.cpp Can you check it to see if anything was missed? Thanks! -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
