Closed Bug 1164602 Opened 4 years ago Closed 4 years ago

Replace NullPtr hack with nullptr_t

Categories

(Core :: JavaScript: GC, defect)

defect
Not set

Tracking

()

RESOLVED FIXED
mozilla41
Tracking Status
firefox41 --- fixed

People

(Reporter: terrence, Assigned: terrence)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file, 1 obsolete file)

When we implemented Handle, nullptr_t was still a typedef to 0 on some platforms. Now that it is a real thing everywhere, we should be able to replace our NullPtr workaround with a constructor taking std::nullptr_t. The only remaining issue is that some platforms do not have a modern libstdc++, so do not have std::nullptr_t. Luckily we can get around that by using decltype(nullptr) instead. This patch appears to work locally; try run is below to check the other platforms:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3b845f5801f5

The attached patch was generated with:
$ find . -name "*.cpp" -o -name "*.h" -exec sed -i 's/JS::NullPtr()/nullptr/g' \{\} \;
$ find . -name "*.cpp" -o -name "*.h" -exec sed -i 's/js::NullPtr()/nullptr/g' \{\} \;
$ find . -name "*.cpp" -o -name "*.h" -exec sed -i 's/NullPtr()/nullptr/g' \{\} \;

With a bit of hand tweaking afterwards to fix up Codegen.py and JS::GCCellPtr::NullPtr.
Whoops! Forgot that the null needs to be at the second level of indirection. Easy enough to solve.

https://treeherder.mozilla.org/#/jobs?repo=try&revision=a53f9c3cec0b
Attachment #8605433 - Attachment is obsolete: true
Attachment #8605513 - Flags: review?(sphink)
Comment on attachment 8605513 [details] [diff] [review]
use_nullptr_t_instead_of_NullPtr-v1.diff

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

::: js/public/RootingAPI.h
@@ +120,5 @@
>  
>  template <typename T>
>  class PersistentRootedBase {};
>  
> +static void*const ConstNullValue = nullptr;

static void* const ConstNullValue = nullptr;

assuming this is still needed?

@@ +407,3 @@
>          static_assert(mozilla::IsPointer<T>::value,
> +                      "nullptr_t overload not valid for non-pointer types");
> +        ptr = reinterpret_cast<const T*>(&js::ConstNullValue);

Wouldn't this be better with just a static nullptr declared right here? Or do we compare these pointers somehow?
Attachment #8605513 - Flags: review?(sphink) → review+
InternalHandle's constructor also needed an &nullptr and I thought it would be simpler to share them. I mean, it would be weird for null handle != null handle, even if we never actually use the feature.
https://hg.mozilla.org/mozilla-central/rev/0deb2843004f
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla41
You need to log in before you can comment on or make changes to this bug.