[Issue 3543] : ? operator can't find common type for interfaces
http://d.puremagic.com/issues/show_bug.cgi?id=3543
--- Comment #2 from nfx...@gmail.com 2009-12-26 10:47:29 PST ---
Note how this makes array literal type inference suck in dmd 2.037:
class Root {
}
class A : Root {
}
class B : Root {
}
bool bla;
void main() {
A a;
B b;
Root t;
t = a; t = b; //works
//Error: cannot implicitly convert expression (a) of type fgd.Root to fgd.B
Root[] t2 = [a, b];
}
If this bug gets fixed, array literal type inference in D2 will be improved.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3650] New: functions are considered pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3650
Summary: functions are considered pointers
Product: D
Version: 1.051
Platform: Other
OS/Version: All
Status: NEW
Keywords: wrong-code
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nfx...@gmail.com
--- Comment #0 from nfx...@gmail.com 2009-12-26 09:45:34 PST ---
First off, this bug report is for dmd 1.053, not 1.051; but bugzilla let's me
only select up to 1.051.
The following code outputs what (void())(), which shows that function
pointers are matched with is(T T2 : T2*). I think this shouldn't be the case:
although technically function pointers really are pointers, D doesn't declare
them using the pointer syntax, doesn't allow them to be dereferenced, and they
don't point to any type.
If this bug is fixed, functions won't match with is(T T2 : T2*) anymore.
If this is just an anti-feature and not a bug, please mark this bug report as
invalid.
struct X {
void function() foo;
}
void moo(T)() {
static if (is(T T2 : T2*)) {
pragma(msg, what ~T2.stringof);
}
}
void main() {
X x;
foreach (int index, z; x.tupleof) {
moo!(typeof(z));
}
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3651] New: mangleof broken for enums
http://d.puremagic.com/issues/show_bug.cgi?id=3651
Summary: mangleof broken for enums
Product: D
Version: 1.051
Platform: Other
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: nfx...@gmail.com
--- Comment #0 from nfx...@gmail.com 2009-12-26 11:32:07 PST ---
First off, this bug report is for dmd 1.053, not 1.051; but bugzilla let's me
only select up to 1.051.
.mangleof is broken for enums:
enum foo {
item,
}
//should output a mangled name with foo in it, but outputs i
pragma(msg, foo.mangleof);
void main() {}
I apologize if this is a duplicate bug; there were quite a lot of enum bugs
which look slightly similar (the compiler seems to reduce enums to ints
prematurely in a lot of cases).
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3646] Default values of function arguments are ignored when instantiating a template.
http://d.puremagic.com/issues/show_bug.cgi?id=3646 --- Comment #2 from Eldar Insafutdinov e.insafutdi...@gmail.com 2009-12-26 12:51:57 PST --- (In reply to comment #1) This is a bit more tricky than it looks like. The question here is, how many times should foo be instanciated? DMD answers just 1 time, and I agree with it, since bar and bam have same signature and mangling. But this only happens if foo!(bar) is instanciated before foo!(bam), because when templates are instantiates on first use. When you instanciate foo!(bam) first, it doesn't get rewritten and therefore fails to compile. I guess the only fix for this issue would be to create an implicit trampoline to invoke functions with default arguments, but only Walter can say for sure. Yeah, that was pretty much what I was thinking about. The issue cuts down to a question, should Foo be instantiated once or are the function types equal? For binary size and efficiency purposes I agree that there should be one instantiation. On the other hand for meta programming and code generation which is what I am doing I would like to have them as separate types, as I don't want to loose this information. Walter or Andrei would probably have to comment on this issue. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3652] Allow implicit casting of dynamic array slices of known size to static array
http://d.puremagic.com/issues/show_bug.cgi?id=3652 --- Comment #1 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-12-26 14:18:34 PST --- So essentially problem is that slices are just dynamic arrays. So bringing back the topic of making slices different/distinctive types. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3650] functions are considered pointers
http://d.puremagic.com/issues/show_bug.cgi?id=3650 Stewart Gordon s...@iname.com changed: What|Removed |Added CC||s...@iname.com --- Comment #1 from Stewart Gordon s...@iname.com 2009-12-26 11:11:08 PST --- I've always been under the impression that immediate function types aren't meant to exist in D, which would mean that the is expression should fail. But there does seem to be some confusion over it. And in any case, the stringof does seem wrong. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3652] Allow implicit casting of dynamic array slices of known size to static array
http://d.puremagic.com/issues/show_bug.cgi?id=3652 --- Comment #2 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-12-26 14:21:40 PST --- It is even worse that i was innitially thinking: explicit casting doesn't work: series2.d(113): Error: e2ir: cannot cast qs[0u..1u] of type float[] to type float[1u] -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3652] New: Allow implicit casting of dynamic array slices of known size to static array
http://d.puremagic.com/issues/show_bug.cgi?id=3652
Summary: Allow implicit casting of dynamic array slices of
known size to static array
Product: D
Version: 2.036
Platform: Other
OS/Version: Linux
Status: NEW
Severity: enhancement
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bary...@smp.if.uj.edu.pl
--- Comment #0 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-12-26
14:17:17 PST ---
Consider this:
void foo(float[4] x) {
return x[0]+x[1]*x[2]-x[3];
}
void main() {
float[] xs = read_floats_from_file();
foreach (i; 0 .. xs.length-4) {
foo(xs[ i .. i+4]);
}
}
or simpler thing to calculate in compile time:
void main() {
float[] xs = read_floats_from_file();
foo(xs[ 0 .. 4]);
}
In both cases compiler will say:
cannot implicitly convert expression (_adDupT((
_D11TypeInfo_Af6__initZ),qs[0u..4u])) of type float[] to float[4u]
or something similar. It is hard to see why this is really needed.
How about allowing (and performing) implicit cast to static array if compiler
knows (or can easly infere) size of the slice and it aggree with target type?
Of course there will be situations where we have no knowledge about it:
void main() {
float[] xs = read_floats_from_file();
uint a = rand() % xs.length;
foo(xs[ 0 .. a ]);
}
But allowing implicit cast also can detect other errors:
foreach (i; 0 .. xs.length-4) {
foo(xs[ i .. i+3]);
}
Compiler in such situation will complain not because we are using float[] to
float[4] conversion, but because we are trying to call float[4] function using
float[3] slice.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3653] New: Problem sorting array of Rebindable
http://d.puremagic.com/issues/show_bug.cgi?id=3653
Summary: Problem sorting array of Rebindable
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: Phobos
AssignedTo: nob...@puremagic.com
ReportedBy: peng2che...@yahoo.com
--- Comment #0 from pc peng2che...@yahoo.com 2009-12-26 15:11:02 PST ---
Created an attachment (id=535)
short test of arrays of Rebindable
Digital Mars D Compiler v2.037
/* The following did not compile. Error deep in phobos due to the line
starting with sort. (comment it out, and no problem).
*/
import std.traits;
import std.stdio, std.algorithm;
class C1 { int x; this(int x){this.x = x;} int y() const { return x; } }
alias Rebindable!(const(C1)) RC1;
void test3() {
RC1[] aCs;
aCs.length = 2;
aCs[0] = new C1(9);
aCs[1] = new C1(10);
aCs ~= RC1(new C1(8));
sort!(a.x b.x)(aCs); //compiles only after hack (see attached file)
foreach(ac; aCs)
writeln(ac.y());
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3654] New: auto return doesn't work for nested functions
http://d.puremagic.com/issues/show_bug.cgi?id=3654
Summary: auto return doesn't work for nested functions
Product: D
Version: 2.036
Platform: Other
OS/Version: Linux
Status: NEW
Severity: major
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: bary...@smp.if.uj.edu.pl
--- Comment #0 from Witold Baryluk bary...@smp.if.uj.edu.pl 2009-12-26
18:55:31 PST ---
Title says it all, example:
module aaa;
void foo() {
auto bar() {
return 1;
}
}
$ dmd2.037 -c aaa.d
aaa.d(2): no identifier for declarator bar
aaa.d(2): semicolon expected, not '{'
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3655] Virtual functions without bodies are not optimized away.
http://d.puremagic.com/issues/show_bug.cgi?id=3655 --- Comment #2 from Eldar Insafutdinov e.insafutdi...@gmail.com 2009-12-27 05:03:55 PST --- Ok, actually I am wrong here, final methods are not optimized away - they just don't exist. And if nobody uses them - you are safe. But the similar behavior should be present for virtual functions as well I believe - virtual function without a body should not be present in vtable. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3655] New: Virtual functions without bodies are not optimized away.
http://d.puremagic.com/issues/show_bug.cgi?id=3655
Summary: Virtual functions without bodies are not optimized
away.
Product: D
Version: 2.035
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: e.insafutdi...@gmail.com
--- Comment #0 from Eldar Insafutdinov e.insafutdi...@gmail.com 2009-12-27
04:12:27 PST ---
This is compiled fine, as final method without a body is optimized away:
class Boo
{
final void foo();
}
However this does not:
class Boo
{
void foo();
}
linker fails with:
main.o:(.rodata+0x194): undefined reference to `_D4main3Boo3fooMFZv'
This might be because function is put into vtable. Is it easy to fix?
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3653] Problem sorting array of Rebindable
http://d.puremagic.com/issues/show_bug.cgi?id=3653 --- Comment #1 from pc peng2che...@yahoo.com 2009-12-26 15:14:42 PST --- (From update of attachment 535) Note: to make this compile without the hack in the attached file, one would have to import std.typecons as well as commenting out the sort line.. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3642] Poor error message: function ___ not callable with argument types ___
http://d.puremagic.com/issues/show_bug.cgi?id=3642 Jason House jason.james.ho...@gmail.com changed: What|Removed |Added Summary|Poor error message when |Poor error message: |using shared: function ___ |function ___ not callable |not callable with argument |with argument types ___ |types ___ | --- Comment #3 from Jason House jason.james.ho...@gmail.com 2009-12-28 21:02:22 PST --- I just came across another example where this is poor. No test case this time ;) Here's the error message: hb/search/factory.d(58): Error: function libego.adapter.move.compressedHash () is not callable using argument types () Any guesses what is wrong? Calling a no argument function is not callable using no arguments? In this particular case, the instance of libego.adapter.move is immutable and the compressedHash function is neither marked as const nor immuatable. The error message really should be better. Example alternate error message: hb/search/factory.d(58): Error: Can't call mutating function on an immutable object. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3611] Enum forward referencing regression
http://d.puremagic.com/issues/show_bug.cgi?id=3611 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-12-28 21:10:00 PST --- Changeset 317 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3655] Virtual functions without bodies are not optimized away.
http://d.puremagic.com/issues/show_bug.cgi?id=3655
--- Comment #1 from Eldar Insafutdinov e.insafutdi...@gmail.com 2009-12-27
04:13:25 PST ---
(In reply to comment #0)
This is compiled fine, as final method without a body is optimized away:
class Boo
{
final void foo();
}
Of course it is optimized away if it is not used.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3656] New: delegate should specify 'this' decorations
http://d.puremagic.com/issues/show_bug.cgi?id=3656
Summary: delegate should specify 'this' decorations
Product: D
Version: 2.036
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: schvei...@yahoo.com
--- Comment #0 from Steven Schveighoffer schvei...@yahoo.com 2009-12-28
06:34:17 PST ---
Note, this bug applies to 2.037, but for some reason it's not in the version
list.
import std.stdio;
class A
{
void f() {}
}
void main()
{
const A a = new A;
auto g = a.f;
writefln(%s, typeof(g).stringof);
g();
}
This outputs:
void delegate()
First, the line:
auto g = a.f;
shouldn't compile because f cannot be called on a. However, even if f is
changed to a const function, the output is still void delegate(), it should
be void delegate() const.
This breaks const correctness without a cast, because I can call g, but not
a.f.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3655] Virtual functions without bodies are not optimized away.
http://d.puremagic.com/issues/show_bug.cgi?id=3655 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added Status|NEW |RESOLVED CC||bugzi...@digitalmars.com Resolution||INVALID --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-12-28 21:14:32 PST --- The compiler is working as designed. The final function is not virtual, so it is never needed in the vtbl[]. Hence, there is no undefined reference to it in the vtbl[]. The non-final function is virtual, and so a reference to it is put into the vtbl[]. The function's implementation must exist somewhere, and if it did, the linker would put a reference to the implementation in the vtbl[]. This feature allows one to have an implementation that is hidden from the user of the class. If you truly do not want to implement the function, declare it as 'abstract'. Then, a NULL is put in the corresponding place in the vtbl[]. Not a bug. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3615] returning .idup of local static array doesn't work in ctfe
http://d.puremagic.com/issues/show_bug.cgi?id=3615 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au --- Comment #1 from Don clugd...@yahoo.com.au 2009-12-28 22:59:06 PST --- This is fixed in DMD2 svn 317 or earlier. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3456] ref foreach over array in CTFE silently fails.
http://d.puremagic.com/issues/show_bug.cgi?id=3456 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED CC||clugd...@yahoo.com.au Resolution||DUPLICATE --- Comment #2 from Don clugd...@yahoo.com.au 2009-12-29 00:12:38 PST --- *** This issue has been marked as a duplicate of issue 1330 *** -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3552] ICE(mtype.c): declaring a variable called 'AssociativeArray' then using an AA.
http://d.puremagic.com/issues/show_bug.cgi?id=3552 Don clugd...@yahoo.com.au changed: What|Removed |Added Keywords||patch --- Comment #4 from Don clugd...@yahoo.com.au 2009-12-29 00:58:15 PST --- PATCH: Instead of trying to instantiate AssociativeArray, do .AssociativeArray instead. Index: mtype.c === --- mtype.c(revision 317) +++ mtype.c(working copy) @@ -3854,13 +3854,14 @@ * But the instantiation can fail if it is a template specialization field * which has Tident's instead of real types. */ -TemplateInstance *ti = new TemplateInstance(loc, Id::AssociativeArray); + Objects *tiargs = new Objects(); tiargs-push(index); tiargs-push(next); -ti-tiargs = tiargs; +DotTemplateInstanceExp *dti = new DotTemplateInstanceExp(loc, new IdentifierExp(loc, Id::empty), Id::AssociativeArray, tiargs); -ti-semantic(sc); +dti-semantic(sc); +TemplateInstance *ti = dti-ti; ti-semantic2(sc); ti-semantic3(sc); impl = ti-toAlias()-isStructDeclaration(); -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3657] No lexical scope for local variables in debug info
http://d.puremagic.com/issues/show_bug.cgi?id=3657 --- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2009-12-29 02:57:56 PST --- Created an attachment (id=536) add lexical scope to local symbols in codeview debug info The patch consists of two parts: 1. modify the parser to remember the end of scope statements. 2. transfer the life-time info to the debug info. The latter is straight forward, but the second part is a bit complicated. As scoping information is lost in the code generation, only the line of declaration and the end of the enclosing scope is remembered by the symbol. The life-time of the variable in terms of code byte offset and length is then reconstructed from the line number info. This is only implemented for CodeView information, as I don't know anything about the other formats. Another complication: optlink removes the corresponding debug entries, so I had to use pseudo-symbols to get this info to cv2pdb and convert them back there. This might confuse other tools, so maybe this feature should be enabled by some command line switch only. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3657] No lexical scope for local variables in debug info
http://d.puremagic.com/issues/show_bug.cgi?id=3657 Rainer Schuetze r.sagita...@gmx.de changed: What|Removed |Added Keywords||patch Priority|P2 |P3 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 --- Comment #12 from Walter Bright bugzi...@digitalmars.com 2009-12-29 03:08:36 PST --- (In reply to comment #11) Changeset 318 Wrong changeset, oops! 318 is for bugzilla 282 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 282] Bizarre circular import nested name invisibility issue
http://d.puremagic.com/issues/show_bug.cgi?id=282 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #4 from Walter Bright bugzi...@digitalmars.com 2009-12-29 03:07:49 PST --- Changeset 318 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 1160] enums can not be forward referenced
http://d.puremagic.com/issues/show_bug.cgi?id=1160 --- Comment #3 from Walter Bright bugzi...@digitalmars.com 2009-12-29 03:19:59 PST --- Changeset 318 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #11 from Walter Bright bugzi...@digitalmars.com 2009-12-29 03:04:14 PST --- Changeset 318 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3600] template instantiation with empty tuple
http://d.puremagic.com/issues/show_bug.cgi?id=3600
Rainer Schuetze r.sagita...@gmx.de changed:
What|Removed |Added
Keywords||patch
CC||r.sagita...@gmx.de
--- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2009-12-29 04:12:05
PST ---
I don't know why this worked before and could not see a change that caused the
regression from version 2.036, but here is a patch that adds an empty type
tuple to the deduced template parameters if it has not yet been created and
does not show up in the function parameters:
Index: template.c
===
--- template.c(revision 317)
+++ template.c(working copy)
@@ -1142,6 +1142,13 @@
/* Fill in any missing arguments with their defaults.
*/
+if(tp fptupindex 0 nargsi == dedargs-dim - 1)
+{ // for variadic type parameters not in function parameters, allow empty
tuple
+Tuple *t = new Tuple();
+dedargs-data[dedargs-dim - 1] = (void *)t;
+nargsi++;
+}
+
for (i = nargsi; i dedargs-dim; i++)
{
TemplateParameter *tp = (TemplateParameter *)parameters-data[i];
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3600] template instantiation with empty tuple
http://d.puremagic.com/issues/show_bug.cgi?id=3600 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Severity|major |regression -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 2029] Typesafe variadic functions don't work in CTFE
http://d.puremagic.com/issues/show_bug.cgi?id=2029 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #13 from Leandro Lucarella llu...@gmail.com 2009-12-29 08:47:27 PST --- http://www.dsource.org/projects/dmd/changeset/314 http://www.dsource.org/projects/dmd/changeset/315 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3628] can't cast null to int
http://d.puremagic.com/issues/show_bug.cgi?id=3628 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-12-29 08:56:03 PST --- http://www.dsource.org/projects/dmd/changeset/316 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3628] can't cast null to int
http://d.puremagic.com/issues/show_bug.cgi?id=3628 --- Comment #3 from Leandro Lucarella llu...@gmail.com 2009-12-29 08:58:06 PST --- http://www.dsource.org/projects/dmd/changeset/316 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 282] Bizarre circular import nested name invisibility issue
http://d.puremagic.com/issues/show_bug.cgi?id=282 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #5 from Leandro Lucarella llu...@gmail.com 2009-12-29 09:02:30 PST --- http://d.puremagic.com/issues/show_bug.cgi?id=282 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3611] Enum forward referencing regression
http://d.puremagic.com/issues/show_bug.cgi?id=3611 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-12-29 08:58:36 PST --- http://www.dsource.org/projects/dmd/changeset/317 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3491] typeof( (string[string]).init)) == AssociativeArray!(string, string), doesn't implicitly convert to string[string].
http://d.puremagic.com/issues/show_bug.cgi?id=3491
Rainer Schuetze r.sagita...@gmx.de changed:
What|Removed |Added
Keywords||patch, rejects-valid
CC||r.sagita...@gmx.de
Severity|normal |regression
--- Comment #1 from Rainer Schuetze r.sagita...@gmx.de 2009-12-29 03:47:45
PST ---
A much simpler version also fails:
void main()
{
int[int] s;
s = s.init;
}
c:\l\dmd-2.036\windows\bin\..\..\src\druntime\import\object.di(294): Error:
cann
ot implicitly convert expression
(_D6object26__T16AssociativeArrayTiTiZ16Associa
tiveArray6__initZ) of type AssociativeArray!(int,int) to int[int]
This used to work for DMD 2.035, so it is a regression.
There seems to be some inconsistency whether to use the new implementation of
associative arrays or the original type.
The following patch ensures usage of the library type for implicitely casting.
Index: mtype.c
===
--- mtype.c(revision 317)
+++ mtype.c(working copy)
@@ -6761,6 +6761,9 @@
{ MATCH m;
//printf(TypeStruct::implicitConvTo(%s = %s)\n, toChars(),
to-toChars());
+if(to-ty == Taarray)
+to = ((TypeAArray*)to)-getImpl()-type;
+
if (ty == to-ty sym == ((TypeStruct *)to)-sym)
{m = MATCHexact;// exact match
if (mod != to-mod)
Index: e2ir.c
===
--- e2ir.c(revision 317)
+++ e2ir.c(working copy)
@@ -3508,6 +3508,12 @@
elem *e = e1-toElem(irs);
Type *tfrom = e1-type-toBasetype();
Type *t = to-toBasetype();// skip over typedef's
+
+if(tfrom-ty == Taarray)
+tfrom = ((TypeAArray*)tfrom)-getImpl()-type;
+if(t-ty == Taarray)
+t = ((TypeAArray*)t)-getImpl()-type;
+
if (t-equals(tfrom))
goto Lret;
This causes some strange cast (pointer to AA - is this supposed to work?) in
object.d to fail, but I could not find the place where this magic happens. So I
changed the definition :
Index: object.di
===
--- object.di(revision 222)
+++ object.di(working copy)
@@ -300,5 +300,7 @@
Value[Key] rehash() @property
{
-return cast(Value[Key]) _aaRehash(p, typeid(Value[Key]));
+Value[Key] aa;
+aa.p = _aaRehash(p, typeid(Value[Key]));
+return aa;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 400] forward reference error; no propety X for type Y (struct within struct)
http://d.puremagic.com/issues/show_bug.cgi?id=400 Walter Bright bugzi...@digitalmars.com changed: What|Removed |Added CC||bugzi...@digitalmars.com --- Comment #1 from Walter Bright bugzi...@digitalmars.com 2009-12-29 16:12:09 PST --- Changeset 319 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3569] DMD Stack Overflow with a struct member function inside a C-style struct initializer
http://d.puremagic.com/issues/show_bug.cgi?id=3569
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
CC||clugd...@yahoo.com.au
--- Comment #2 from Don clugd...@yahoo.com.au 2009-12-29 12:32:09 PST ---
This patch to AssertExp::interpret() prevents the stack overflow, turning it
into a simple error message. It doesn't patch the regression.
As Rob notes, the static struct initializers are evaluated at compile time, but
they shouldn't be. Nonetheless, this patch is still required to prevent
segfaults in the case where they are forcibly evaluated at compile time. Eg,
code like the following:
struct Foo {
Foo bar() { return this; }
}
struct Bar {
Foo foo;
int fog() {
enum Bar r = { foo.bar() };
return 3;
}
}
PATCH ---
Index: interpret.c
===
--- interpret.c(revision 318)
+++ interpret.c(working copy)
@@ -2535,14 +2535,18 @@
if( this-e1-op == TOKaddress)
{ // Special case: deal with compiler-inserted assert(this, null
this)
AddrExp *ade = (AddrExp *)this-e1;
-if(ade-e1-op == TOKthis istate-localThis)
-return istate-localThis-interpret(istate);
+if(ade-e1-op == TOKthis istate-localThis)
+if (istate-localThis-op==TOKdotvar
+ ((DotVarExp *)(istate-localThis))-e1-op==TOKthis)
+return getVarExp(loc, istate, ((DotVarExp
*)(istate-localThis))-var);
+else
+return istate-localThis-interpret(istate);
}
-if (this-e1-op == TOKthis)
-{
+if (this-e1-op == TOKthis)
+{
if(istate-localThis)
-return istate-localThis-interpret(istate);
-}
+return istate-localThis-interpret(istate);
+}
e1 = this-e1-interpret(istate);
if (e1 == EXP_CANT_INTERPRET)
goto Lcant;
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 400] forward reference error; no propety X for type Y (struct within struct)
http://d.puremagic.com/issues/show_bug.cgi?id=400 Leandro Lucarella llu...@gmail.com changed: What|Removed |Added CC||llu...@gmail.com --- Comment #2 from Leandro Lucarella llu...@gmail.com 2009-12-29 19:17:26 PST --- http://www.dsource.org/projects/dmd/changeset/319 -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3442] scope(exit) Problem
http://d.puremagic.com/issues/show_bug.cgi?id=3442 Don clugd...@yahoo.com.au changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID --- Comment #2 from Don clugd...@yahoo.com.au 2009-12-29 22:12:51 PST --- I'm closing this as invalid since it has no test case. But it is probably a duplicate of one of the bugs I mentioned. Reopen if you have a complete test case. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3658] New: Crashing on vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=3658 Summary: Crashing on vector operations Product: D Version: unspecified Platform: Other OS/Version: Mac OS X Status: NEW Severity: normal Priority: P2 Component: DMD AssignedTo: nob...@puremagic.com ReportedBy: d-issue-trac...@braxtech.com --- Comment #0 from Braxton d-issue-trac...@braxtech.com 2009-12-30 08:21:09 PST --- Created an attachment (id=538) Reduction Overview: Vector operations using the concise notation (i.e. array[] += 0.5f) are crashing under DMD 2.037 running on Mac OS X 10.6.2. When these operations are replaced with a corresponding foreach loop of the same functionality, the crash does not occur. Steps to Reproduce: 1) Download the attached reduction 2) Build and run with DMD 2.037 under Mac OS X 10.6.2 Actual Results: The application crashed with the attached crash log. Expected Results: The application should return successfully. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3658] Crashing on vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=3658 --- Comment #1 from Braxton d-issue-trac...@braxtech.com 2009-12-30 08:21:42 PST --- Created an attachment (id=539) Crash Log -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3658] Crashing on vector operations
http://d.puremagic.com/issues/show_bug.cgi?id=3658 Braxton d-issue-trac...@braxtech.com changed: What|Removed |Added CC||d-issue-trac...@braxtech.co ||m Severity|normal |major -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3659] New: Too much exegesis on opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=3659
Summary: Too much exegesis on opEquals
Product: D
Version: unspecified
Platform: Other
OS/Version: Linux
Status: NEW
Severity: normal
Priority: P2
Component: DMD
AssignedTo: nob...@puremagic.com
ReportedBy: and...@metalanguage.com
--- Comment #0 from Andrei Alexandrescu and...@metalanguage.com 2009-12-30
09:14:06 PST ---
struct A {
bool opEquals(int x) {
return false;
}
}
Compiler says:
Error: function test.A.opEquals type signature should be const bool(ref
const(A)) not bool(int x)
The compiler should accept any signature for opEquals. All it needs to do is
rewrite a == b into a.opEquals(b) or b.opEquals(a).
For classes I'm doubtful that opEquals needs to be const.
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3659] Too much exegesis on opEquals
http://d.puremagic.com/issues/show_bug.cgi?id=3659 Richard Webb we...@beardmouse.org.uk changed: What|Removed |Added CC||we...@beardmouse.org.uk --- Comment #1 from Richard Webb we...@beardmouse.org.uk 2009-12-30 09:42:14 PST --- Same as #3607 ? -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3583] Regression(DMD2.037): Unsigned right shift works the same as signed right shift.
http://d.puremagic.com/issues/show_bug.cgi?id=3583 Don clugd...@yahoo.com.au changed: What|Removed |Added CC||clugd...@yahoo.com.au Version|future |2.036 Summary|Unsigned right shift works |Regression(DMD2.037): |the same as signed right|Unsigned right shift works |shift. |the same as signed right ||shift. --- Comment #2 from Don clugd...@yahoo.com.au 2009-12-30 11:26:03 PST --- Doesn't seem to happen on DMD1. Code works on DMD1.054beta. -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
[Issue 3583] Regression(DMD2.037): Unsigned right shift works the same as signed right shift.
http://d.puremagic.com/issues/show_bug.cgi?id=3583
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Don clugd...@yahoo.com.au 2009-12-30 12:06:31 PST ---
Root cause: A bad refactoring that dropped the conversion to unsigned.
PATCH: e2ir.c, line 3008 and 3113 UshrExp::toElem() and UshrAssignExp::toElem()
Copy the code from D1.
elem *UshrAssignExp::toElem(IRState *irs)
{
-return toElemBin(irs, OPshrass);
+elem *eleft = e1-toElem(irs);
+eleft-Ety = touns(eleft-Ety);
+elem *eright = e2-toElem(irs);
+elem *e = el_bin(OPshrass, type-totym(), eleft, eright);
+el_setLoc(e, loc);
+return e;
}
elem *UshrExp::toElem(IRState *irs)
{
-return toElemBin(irs, OPshr);
+elem *eleft = e1-toElem(irs);
+eleft-Ety = touns(eleft-Ety);
+elem *eright = e2-toElem(irs);
+elem *e = el_bin(OPshr, type-totym(), eleft, eright);
+el_setLoc(e, loc);
+return e;
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3270] pure functions returning struct
http://d.puremagic.com/issues/show_bug.cgi?id=3270
Don clugd...@yahoo.com.au changed:
What|Removed |Added
Keywords||patch
--- Comment #2 from Don clugd...@yahoo.com.au 2009-12-30 13:11:55 PST ---
Shouldn't be doing no-side-effect calls if there's a hidden parameter.
This happens if the value is being returned on the stack.
PATCH (e2ir.c line 287):
else if (ep)
-e = el_bin((tf-ispure tf-isnothrow) ? OPcallns : OPcall,tyret,ec,ep);
+e = el_bin((tf-ispure tf-isnothrow (retmethod != RETstack)) ?
OPcallns : OPcall,tyret,ec,ep);
else
-e = el_una((tf-ispure tf-isnothrow) ? OPucallns : OPucall,tyret,ec);
+e = el_una((tf-ispure tf-isnothrow (retmethod != RETstack)) ?
OPucallns : OPucall,tyret,ec);
---
TEST CASE:
struct Foo {
int x, y;
real z;
}
pure nothrow Foo makeFoo(const int x, const int y) {
return Foo(x, y, 3.0);
}
void main()
{
auto f = makeFoo(1, 2);
assert(f.x==1);
assert(f.y==2);
assert(f.z==3);
}
--
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
[Issue 3198] wrong initializer for structs arrays
http://d.puremagic.com/issues/show_bug.cgi?id=3198 --- Comment #2 from Don clugd...@yahoo.com.au 2009-12-30 14:56:32 PST --- Or else, create a new version of TypeStruct::toDtElem, which doesn't have the special-case for structs members, and call it from StructDeclaration::toDt() and ClassDeclaration::toDt2() -- Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email --- You are receiving this mail because: ---
