If a and b are TypeInfo, a==b can return true, even if a and b refer to different types (and object instances). Both Phobos and Tango are affected.
The code example at the end of this report demonstrates this. The second assertion fails, because opEquals() returns true when comparing two different TypeInfos. This is because opEquals compares the two TypeInfo by their toString() results. The returnd string doesn't contain any information about the delegate parameters, ths delegates with the same return type are considered equal.
I wonder if TypeInfo.opEquals() shouldn't only compare the addresses of the TypeInfo objects. The string comparision seems pointless, even if you use DLLs. With DLLs, you should either not attempt to use objects from another instance of the runtime, or you should use proper solutions like DDL, which enables to DLLs to share the same runtime. The string comparision hack is hard to get right, because the compiler needs just another method to encode the complete information about a type as string. (A better hack would be to compare the mangled symbol names.)
//program will execute successfully if bug is fixed
class X {
void a() {}
void b(int z, short c) {}
}
void main() {
auto z = new X();
TypeInfo a = typeid(typeof(&z.a));
TypeInfo b = typeid(typeof(&z.b));
//doesn't fail (ok)
assert(a !is b, "1");
//fails (which is wrong, because both TypeInfos are different!)
assert(a != b, "2");
}
Comment #1 by nfxjfg — 2010-06-07T20:18:41Z
Attributes such as pure are also ignored.
Comment #2 by nfxjfg — 2010-06-07T20:20:14Z
*** Issue 3831 has been marked as a duplicate of this issue. ***