Comment #0 by bus_dbugzilla — 2012-01-27T00:22:38Z
a.d:
----------------
import b;
void main(string[] args)
{
auto foo = getEleven();
//auto dummy = cast(Derived!11)foo;
assert(cast(Derived!22)foo is null);
}
alias DerivedAlias!22 X;
----------------
b.d:
----------------
module b;
Base getEleven()
{
Base foo = new MoreDerived!11(null);
return foo;
}
class Base
{
Base a;
this(Base a)
{
this.a = a;
}
}
class Derived(int i) : Base
{
this(Base a)
{
super(a);
}
}
class MoreDerived(int i) : Derived!i
{
this(Base a)
{
super(a);
}
}
template DerivedAlias(int i)
{
alias Derived!i DerivedAlias;
}
----------------
On 2.057, the assert fails. (It's fine on 2.056.)
If you uncomment the "dummy" line, the problem goes away (merely creating an alias for Derived!11 does not work). However, that's *not* a general workaround because in order to test what the runtime type is, you have to *already* know *all* the types it might be and attempt to downcast to each of them.
Comment #1 by bus_dbugzilla — 2012-01-27T00:26:47Z
Sorry, I forgot to finish minimizing "b.d". The properly minimized "b.d" is:
--------------------
module b;
Base getEleven()
{
Base foo = new MoreDerived!11();
return foo;
}
class Base {}
class Derived(int i) : Base {}
class MoreDerived(int i) : Derived!i {}
template DerivedAlias(int i)
{
alias Derived!i DerivedAlias;
}
--------------------
Comment #2 by bugzilla — 2012-01-29T22:16:19Z
A one file version:
-------------------
class A {}
class B(int i) : A {}
class C(int i) : B!i {}
template DerivedAlias(int i)
{
alias B!i DerivedAlias;
}
alias DerivedAlias!22 X;
void main(string[] args)
{
A foo = new C!11();
//auto dummy = cast(B!11)foo;
assert(cast(B!22)foo is null);
}
Comment #3 by bugzilla — 2012-01-30T01:20:02Z
The failure definitely happened between 2.056 and 2.057. Anyone care to run the git binary diff thing?
Comment #4 by bugzilla — 2012-01-30T02:02:19Z
Auch, I found it. In druntime/src/rt/cast_.d, the addition of a name compare saying the classes are the same in _d_isbaseof and _d_isbaseof2.
Not sure what the right fix is.
I suspected is was that commit. (I remember seeing it when it was committed) Sorry I didn't get around to looking into it earlier.
I think the solution is to do a compare on the full mangled name of the class, but I can't see anywhere it's exposed in the classinfo so it would need to be added.
This should probably be delayed until after the release and the commit reverted.