Example from bug 816784: void js::WrapperMap::Enum::popFront() void js::WrapperMap::Enum::goToNext() uint8 BrowserCompartmentMatcher::match(JSCompartment*) const uint8 nsContentUtils::IsSystemOrExpandedPrincipal(nsIPrincipal*) uint8 nsContentUtils::IsExpandedPrincipal(nsIPrincipal*) nsCOMPtr<T>::nsCOMPtr(nsQueryInterface) [with T = nsIExpandedPrincipal] nsCOMPtr<T>::nsCOMPtr(nsQueryInterface) [with T = nsIExpandedPrincipal] void nsCOMPtr<T>::assign_from_qi(nsQueryInterface, const nsIID&) [with T = nsIExpandedPrincipal; nsIID = nsID] uint32 nsQueryInterface::operator(nsID*, void**)(const nsIID&, void**) const FieldCall: nsISupports.QueryInterface It would be really nice if that could be nsIExpandedPrincipal.QueryInterface, since then the analysis could devirtualize and know whether any implements can GC.

mccr8, do you know offhand whether this would be doable? It's macro soup there, so I guess I should look at a preprocessed file.

This would probably be easier if nsCOMPtr<T> actually contained T* in opt builds, rather than nsISupports*.

I don't really know offhand. I think it wouldn't be too unreasonable to have a requirement like saying that all QI for a class that inherits only from non-scriptable nsISupports subclasses don't GC. Or something. Standard QIs only do the equivalent of static_casts. nsQueryInterface::operator() also isn't templated, which will presumably be an issue. I don't know if there are code bloat issues, or if any reasonable compiler will merge stuff together nowadays, if that was templated.