What sort of static analysis pass is needed? Is it something our plugins crate can do?
Also, my Reflector/InheritancePass PR provides match_unwrap_ty(), so linting for Vec<Temporary<T>> is potentially a one line change (+boilerplate). -----Original Message----- From: "Josh Matthews" <[email protected]> Sent: 12/9/2014 3:11 AM To: "[email protected]" <[email protected]> Subject: [dev-servo] SpiderMonkey upgrade blockers Based on jonco's review of the previous upgrade work, here are the pieces that I think are important enough to block the upgrade from landing until they are complete: * implement RootedVec<T>, replace all uses of Vec<Rooted<T>> - ideally, this will be binary-compatible with AutoVectorRooter<T> from jsapi.h, so we can pass them to APIs that take &AutoIdVector values. If not, we can just convert between them in rust-mozjs/glue.cpp - uses GC hook to trace all known stack collections - can be based on https://github.com/jdm/servo/commit/771d319168204e58b4c0c3d68a82a63259814d25#diff-7fa3011afc74ee7695cb180db1da7791R248 and https://github.com/jdm/servo/commit/3ca013d3c587586e24f1f476e826cc7f956d0c44#diff-7fa3011afc74ee7695cb180db1da7791R254 * implement replacement for Vec<Temporary<T>> - I don't have a great idea here. All I've been able to come up with is more types like NodeList that are WebIDL-based and [NoInterfaceObject] so they don't leak into web content * implement lint to ban Vec<Temporary<T>>, Vec<Rooted<T>> - dependent on solving the previous two tasks, to avoid security regressions * implement the equivalent of MutNullableJS<T> for heap SM primitives (ie. JSVal, *mut JSObject) - these will need write barriers post-upgrade - see https://github.com/jdm/servo/commit/771d319168204e58b4c0c3d68a82a63259814d25#diff-77e42f966279a10a63070b5c62117a56R289) * extract https://github.com/jdm/servo/commit/c824acd71ef98177f2b878d62c7111aede502f77 - this doesn't actually belong in the upgrade, and extracting independent commits out of it is a righteous (and easy) goal. Everything above this line can be implemented independent of the upgrade, making the actual upgrade much easier (such as mereley implementing missing write barriers). Everything below this line is work that needs to happen on the upgrade branch. * figure out why NSPR hacks were needed (https://github.com/servo/mozjs/commit/5869198ea31f911da76993c47f6a9de04ddf5fb7, https://github.com/servo/rust-mozjs/commit/6e91b33f7749bcacb4fa4cae8d8304e4a3cbf0b6, https://github.com/jdm/servo/commit/9bf03511947a31d91d8c274b5f1d6e297a1da492#diff-eeefd668773bcf179c9bdcf09d495b27R347) - jorendorff was confused when I called out the NSPR/pthread TLS stuff as making the upgrade difficult. I don't remember why this was needed precisely. * allow the JS tracing code to obtain a *mut *mut JSObject from the reflector - there's an assertion that the reflector is not moved while tracing occurs. I think we can do better now that as_unsafe_cell exists Apart from these tasks, jonco called out the lack of a similar static analysis pass as Gecko's as being problematic. I agree, but it's something that I'd really like to do independent of the upgrade, rather than hold up all progress on it. I would especially welcome volunteers to tackle the items that can be implemented in the master branch today. Cheers, Josh _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo _______________________________________________ dev-servo mailing list [email protected] https://lists.mozilla.org/listinfo/dev-servo
