Closed Bug 792790 Opened 10 years ago Closed 10 years ago

Adapt translator/Java source to nullptr


(Core :: DOM: HTML Parser, defect)

Not set





(Reporter: hsivonen, Assigned: hsivonen)




(1 file, 3 obsolete files)

The global change from nsnull to nullptr manually changed generated parser code so that some nsnull instances became nullptr and some became 0. Need to change the translator and/or the Java code so that translation results in proper nsnull-free output.
Depends on: 626472
Summary: Adapts traslator/Java source to nullptr → Adaps translator/Java source to nullptr
Summary: Adaps translator/Java source to nullptr → Adapt translator/Java source to nullptr
Attached patch Adapt to nullptr (obsolete) — Splinter Review
The cases where nsnull was changed to 0 instead of nullptr in the files that are supposed to be generated fell into two categories:
1) Invoking the special operator= in autoJArray
2) Representing undefined namespace when the accessor is called with an out-of-bounds index.

I addressed the first case by editing jArray.h. To address the second case, I opted to remove the handling for out-of-bounds indeces, because the accessors are always called with a valid index into Gecko thanks to the way the index is obtained at all call sites. On the Java side, I added variants of the by-index accessors that's don't check for out-of-bounds. I then exposed to these new accessors to C++ instead of the old ones. The assertions that I added on the Java side but that don't get translated to C++ yet are there in anticipation of bug 503190. Note that the assertions are unnecessary in Java, because the JVM is guaranteed to check for array bounds anyway.
Assignee: nobody → hsivonen
Attachment #662963 - Attachment is obsolete: true
Attachment #664889 - Flags: review?(bugs)
Comment on attachment 664889 [details] [diff] [review]
Adapt to nullptr, with OS X compiler support

Argh. This still causes compiler warnings.
Attachment #664889 - Flags: review?(bugs)
I give up trying to get rid of compiler warnings. In GCC 4.6.3 decltype(nullptr) seems to be long int rather than std::nullptr_t. Sigh.
Attachment #664889 - Attachment is obsolete: true
Attachment #664931 - Attachment is obsolete: true
Attachment #665344 - Flags: review?(bugs)
Attachment #665344 - Flags: review?(bugs) → review+
Closed: 10 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla18
Depends on: 796925
You need to log in before you can comment on or make changes to this bug.