1278929 - use std::unique_ptr in DocAccessible::AttrRelProviderArray

Status: NEW

(Core :: Disability Access APIs, defect)

Comment 1

[Trevor Saunders (:tbsaunde)]

Attachment: use std::unique_ptr in DocAccessible::AttrRelProviderArray

Not all that great since we need to borrow the pointer a bit, but it removes usage of nsAutoPtr

Comment 2

[Nathan Froyd [:froydnj]]

Comment on attachment 8761261 [details] [diff] [review]
use std::unique_ptr in DocAccessible::AttrRelProviderArray

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

r=me.  I think the changes below to not use .get() are preferable, but I'll leave the decision up to you.

::: accessible/base/AccIterator.cpp
@@ +95,5 @@
>    if (!mProviders)
>      return nullptr;
>  
>    while (mIndex < mProviders->Length()) {
> +    const DocAccessible::AttrRelProvider* provider = (*mProviders)[mIndex++].get();

If you wanted, you could make this:

const std::unique_ptr<DocAccessible::AttrRelProvider>& provider = ...;

since provider isn't passed to anything expecting a raw pointer.

::: accessible/generic/DocAccessible.cpp
@@ +119,5 @@
>      for (int32_t jdx = providers->Length() - 1; jdx >= 0; jdx--) {
>        NS_CYCLE_COLLECTION_NOTE_EDGE_NAME(
>          cb, "content of dependent ids hash entry of document accessible");
>  
> +      AttrRelProvider* provider = (*providers)[jdx].get();

Same thing here, I think.

Comment 3

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/af41c2ddcb5a
use std::unique_ptr in DocAccessible::AttrRelProviderArray r=froydnj

Comment 4

[Carsten Book [:Tomcat]]

sorry had to back this out for bustage like https://treeherder.mozilla.org/logviewer.html#?job_id=30781711&repo=mozilla-inbound

Comment 5

[Pulsebot]

Backout by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/a93a814b1369
Backed out changeset af41c2ddcb5a for bustage on a CLOSED TREE

Comment 6

[BugBot [:suhaib / :marco/ :calixte]]

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit auto_nag documentation.