545052 - Tools to assist deCOMtamination

Status: RESOLVED INVALID

(Developer Infrastructure :: Source Code Analysis, defect)

Description

[Zack Weinberg (:zwol)]

Over in bug 513149 I was complaining about the tediousness of doing deCOMtamination with no mechanical assistance.  I don't think we can easily get tools that do everything for us, but I think we could automate simple cases, and there are plenty of simple cases.

Here's what I'd like:

1) A tool which can scan the tree (or the DXR database) and identify easy deCOM candidates. To be an easy deCOM candidate, an interface class should:

 - not be defined in an IDL file
 - not be exposed to C++ extensions or js-ctypes (I don't know how you detect this)
 - inherit nsISupports but no other classes
 - not participate in cycle collection
 - not be a service
 - have exactly one implementation in the tree
 - implementation objects should be allocated and freed with plain old new/delete

2) A rewriting tool that finds all files that include "nsIWhatever.h" and either deletes the #include, changes it to "nsWhatever.h", or replaces it with a forward declaration of nsWhatever, depending on what uses it sees in the file.

3) A rewriting tool that converts nsCOMPtr<nsIWhatever> to nsRefPtr<nsWhatever> throughout the tree.

4) A rewriting tool that converts uses of do_CreateInstance("@mozilla.org/whatever;1") and NS_NewWhatever to bare new nsWhatever().  This should also be able to find and delete the definition and declaration of NS_NewWhatever and the table entries for do_CreateInstance.

5) A rewriting tool that can merge the class declarations for nsIWhatever and nsWhatever, purge all COM-related macros, and devirtualize all the method declarations.  It is okay if the result of this has to be audited by a human.

I'm considering any further API cleanup to be out-of-scope for these tools; I think scope creep is one of the things that has torpedoed deCOM projects in the past.  We can do outparamdel, always-returns-NS_OK-becomes-void, implementation hiding, etc. etc. separately.

There is a sixth thing that we badly need: canned AddRef/Release implementations for use with nsRefPtr, that don't drag in QueryInterface as well.  But that's not a rewriting tool, so I've filed it separately, as bug 545050.

Comment 1

[Zack Weinberg (:zwol)]

I just noticed https://wiki.mozilla.org/Gecko:DeCOMtamination_Algorithm which seems to go well with the above list.

A problem that came up for me in bug 544112, and also seems to have stalled out bug 455595 and its successor bug 458300, is that if you devirtualize an entire class, sometimes cross-shared-library references to a method or two cease to be resolvable.  This is mainly a problem for --disable-libxul, but since we still need that, it remains a problem.

Comment 2

[Andi [:andi]]

We no longer use those data types.