Closed
Bug 545052
Opened 15 years ago
Closed 4 years ago
Tools to assist deCOMtamination
Categories
(Developer Infrastructure :: Source Code Analysis, defect)
Developer Infrastructure
Source Code Analysis
Tracking
(Not tracked)
RESOLVED
INVALID
People
(Reporter: zwol, Unassigned)
References
(Blocks 1 open bug, )
Details
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.
Updated•15 years ago
|
Blocks: static_analyses
Reporter | ||
Comment 1•15 years ago
|
||
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.
Updated•7 years ago
|
Product: Core → Firefox Build System
Comment 2•4 years ago
|
||
We no longer use those data types.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
Updated•2 years ago
|
Product: Firefox Build System → Developer Infrastructure
You need to log in
before you can comment on or make changes to this bug.
Description
•