It seems that there are 3 stages to doing a rewrite in Moz:
- Start a new tool. Make sure that it can rewrite some trivial testcases. Add lots of asserts for cases you are unsure about.
- Run tool on Mozilla and fix crashes caused by above asserts. Get 80% of the code rewriting correctly.
- Get the other 20% rewriting. This often involves major overhauls to rewriting logic due to patterns that weren’t expected when the spec was written
Usually stage 3 is a few times harder than 2. For garburator rewriting got really hard in stage 3. 90% of my time ended up being spent in stage 3 due to fun issues like figuring out what to do with unforeseen(in spec) combination of references and nsCOMPtr<>s.
With exceptions step 2 is already getting hard. So far I’ve had to extend elsa to support pattern matching, and reworked the code patcher to support recursive rewriting.
Now looks like I’ll need to do some flow-sensitive analysis to rewrite cases like nsMemoryImpl::FlushMemory. I’m not sure if it is possible to automatically deal with functions like nsExceptionService::DoGetExceptionFromProvider.
Also, I’m not yet rewriting code to be bugfree, just trying to get it to compile. Once exceptioned code compiles, step two will be to statically check code to verify that it is exception-safe and convert it to RAII or something.
Here is an current patch for xpcom/ produced by thrower. At the moment there are still a lot of pattern matches to be added. It mostly handles rv = foo(); if (NS_FAILED(rv)) and a few other simple cases.
This is exciting stuff, but really hard, so if anyone has exciting problem solving ideas feel free to ping me.