There is a very strange compilation issue with MSVC7 where the compiler complains about not being able to convert pointers to Node subclasses to a Node* when calling append on a Vector<Node*> type. See the <NodeSubclass>::getDeclarations methods in JavaScriptCore/kjs/nodes.cpp to see what cases cause the error. So far, I've been unable to track down if MSVC7 is not happy with something about how Node is defined, if there is an issue with placement new, or if there is an issue with the code in Vector<T, inlineCapacity>::append(const U& val). I'm not too familiar with this code, but thanks to help from Darin, Maciej and Eric, I was able to do some debugging (calling the variant of expandCapacity that does not take and return a U*, and running various tests on new) but so far, nothing except running an explicit cast on the *ptr fixes the issue. That solution won't work, however, as then it no longer will do implicit casting between types. Since MSVC8 compiles the code fine and MSVC7 isn't freely available, it's hard to find others to reproduce this, but fixing this would be very helpful to the wx port as we could resume building Python extensions. We are going to look at alternatives to using MSVC7 but in the meantime I'm adding this bug report to keep track of the issue without having it hold back progress on the wx port migration.
MSVC7 error message when trying to compile JavaScriptCore/kjs/nodes.cpp. Note that we'll get this error even if there isn't a difference in the const-ness between the variables. In general, it seems it doesn't allow down-casting, or at least of Node-based subclasses. wtf\Vector.h(668) : error C2440: 'initializing' : cannot convert from 'KJS::VarDeclListNode *const ' to 'KJS::Node *' kjs\nodes.cpp(1698) : see reference to function template instantiation ' void WTF::Vector<T,inlineCapacity>::append<KJS::VarDeclListNode*>(const U & )' being compiled with [ T=KJS::Node *, inlineCapacity=16, U=KJS::VarDeclListNode * ] wtf\Vector.h(668) : fatal error C1903: unable to recover from previous error(s); stopping compilation NMAKE : fatal error U1077: 'cl' : return code '0x2'
Created attachment 17766 [details] Problem workaround If someone could find a better solution, I'd be greatly appreciative, but in the meantime this patch only changes behavior for the broken compiler, and this at least allows us to continue on the Windows wxPython bindings, which is anxiously anticipated by a number of users.
Comment on attachment 17766 [details] Problem workaround Unpleasant, but seems OK. r=me
landed in r28517