1315812 - Mark nsISupportsArray, nsICollection, nsIEnumerator as deprecated

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Eric Rahm [:erahm]]

This marks the idl classes as deprecated, removes an unnecessary include that
was triggering deprecation warnings and wraps a necessary include in
XPCOMInit.cpp that is used for registering the component in deprecation
disabling pragmas.

MozReview-Commit-ID: BbNU5q8O4Q4

Comment 1

[Eric Rahm [:erahm]]

Attachment: Mark nsISupportsArray, nsICollection, nsIEnumerator as deprecated

Comment 2

[Nathan Froyd [:froydnj]]

Comment on attachment 8808395 [details] [diff] [review]
Mark nsISupportsArray, nsICollection, nsIEnumerator as deprecated

Review of attachment 8808395 [details] [diff] [review]:
-----------------------------------------------------------------

r=me, I guess, though I'd like to understand why we only need the single deprecation location.

::: xpcom/build/XPCOMInit.cpp
@@ +44,5 @@
> +#pragma GCC diagnostic push
> +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> +#elif defined(_MSC_VER)
> +#pragma warning (push)
> +#pragma warning (disiable : 4996)

"disiable"? :)

@@ +51,1 @@
>  #include "nsSupportsArray.h"

How is this the only place that requires the deprecation suppression?  Surely the implementation code somewhere includes the deprecated .h files...

Comment 3

[Eric Rahm [:erahm]]

Attachment: Mark nsISupportsArray, nsICollection, nsIEnumerator as deprecated

Now with more pragmas

Comment 4

[Eric Rahm [:erahm]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/f424e29dc77ed2790f3ab6e05940a31c4a85316a
Bug 1315812 - Mark nsISupportsArray, nsICollection, nsIEnumerator as deprecated. r=froydnj

Comment 5

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/mozilla-central/rev/f424e29dc77e

Comment 6

[:aceman]

It could be better for all external users if this went into 53. Forcing changing of interfaces (due to compiler warnings-as-errors) so close before branching of 52 ESR is not nice.

Comment 7

[Nathan Froyd [:froydnj]]

(In reply to :aceman from comment #6)
> It could be better for all external users if this went into 53. Forcing
> changing of interfaces (due to compiler warnings-as-errors) so close before
> branching of 52 ESR is not nice.

You can apply the workarounds for C++ from this very bug; you don't have to change any interfaces.

Comment 8

[Jorg K (CEST = GMT+2)]

We did ;-)

Nathan, when will M-C remove nsISupportsArray completely? We still use it extensively in Thunderbird, despite our best ongoing efforts to remove it. It's mainly used in the search component.

Comment 9

[Nathan Froyd [:froydnj]]

(In reply to Jorg K (GMT+1) from comment #8)
> We did ;-)
> 
> Nathan, when will M-C remove nsISupportsArray completely? We still use it
> extensively in Thunderbird, despite our best ongoing efforts to remove it.
> It's mainly used in the search component.

I believe Eric was planning on removing it after a single release advertising its deprecation, so in 53.  Is that correct, Eric?  I suppose we could consider other options, especially since it just got more inconvenient to use from C++...

Comment 10

[Eric Rahm [:erahm]]

(In reply to Nathan Froyd [:froydnj] from comment #9)
> (In reply to Jorg K (GMT+1) from comment #8)
> > We did ;-)
> > 
> > Nathan, when will M-C remove nsISupportsArray completely? We still use it
> > extensively in Thunderbird, despite our best ongoing efforts to remove it.
> > It's mainly used in the search component.
> 
> I believe Eric was planning on removing it after a single release
> advertising its deprecation, so in 53.  Is that correct, Eric?  I suppose we
> could consider other options, especially since it just got more inconvenient
> to use from C++...

I think kmag and I settled on a full release cycle so that addon devs can put out one release that works with all of ours, so remove when 52 (or is it 53?) hits release. I'd be happy to remove earlier of course!

If we can't remove the dependencies in TB by that time then another option is to move the interface into c-c at that point.