Closed Bug 1761804 Opened 4 years ago Closed 4 years ago

Remove NS_COORD_IS_FLOAT macro

Categories

(Core :: Layout, task)

task

Tracking

()

RESOLVED FIXED
100 Branch
Tracking Status
firefox100 --- fixed

People

(Reporter: dholbert, Assigned: dholbert)

References

Details

Attachments

(1 file)

NS_COORD_IS_FLOAT isn't checked in too many places:
https://searchfox.org/mozilla-central/search?q=NS_COORD_IS_FLOAT&path=
...which means it's almost-certainly woefully incomplete as an actual list of stuff-that-would-need-to-change-if-we-changed-nscoord-to-float.

Also, I don't think that "make nscoord a float" is a change we're planning on making any time soon (or maybe ever).

In light of this: to clean up & simplify code, I think we should just get rid of NS_COORD_IS_FLOAT, and consider nscoord to canonically be an integer (as we already do in practice).

If we someday decide to change it to a float, we can pull this bug's patch(es) out of the archive to see places where we might want to start on the conversion. But it's not useful or healthy to have them just sitting as dead/untested ancient code inside the tree, IMO.

jrmuizel/emilio: any thoughts/objections?

See Also: → 265084

This sounds good to me. Neither WebKit nor Blink use floats for layout right?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #1)

This sounds good to me. Neither WebKit nor Blink use floats for layout right?

I thought Blink does? But I might be wrong. emilio is more familiar with the state of Blink/WebKit source code and can probably answer...

Flags: needinfo?(emilio)

Also worth noting: I just tried to build with NS_COORD_IS_FLOAT defined, and unsurprisingly we hit build failures all over the place.

Looking at the pile that I get before I fully error out, they're mostly in 3 buckets:
(1) std::min() / std::max() expressions that compare a nscoord to an int32_t, or to a numeric literal e.g. 0 which implicitly is of type int. If nscoord is float, then those expressions would now be comparing float to an int, for which std::min/max functions do not exist.

(2) There's some ifdeffed code in nsCoord.h that uses APIs (e.g. mozilla::PositiveInfinity) without ensuring that the appropriate headers are included, so those trigger build errors in many places that are missing the header.

(3) There are "narrowing conversion" errors ("error: type 'float' cannot be narrowed to 'int32_t' (aka 'int') in initializer list [-Wc++11-narrowing]") for some float-to-int conversions that we have to do as a result of making nscoord a float.

There are probably more categories of build errors, too, that my build just didn't reach yet before erroring out.

This patch just assumes NS_COORD_IS_FLOAT is undefined (which in practice it
always is), and deletes dead code accordingly.

It's unlikely we'll migrate nscoord to float anytime soon, so this code isn't
serving much of a purpose at this point. If we do someday make that migration,
the code that this macro is guarding would only represent a small step in that
migration, anyway; and at that point we can start by adding back the code that
this patch is removing.

In the meantime, it's not worth keeping this complexity and the untested/dead
code in the tree.

Assignee: nobody → dholbert
Status: NEW → ASSIGNED

(adding bug 1726620 to see-also; TYLin did some work there to introduce new strongly-typed nscoord-like types, to let us use 64-bit integers for certain isolated pieces of layout where we need to be able to represent larger values.)

See Also: → 1726620

Thanks!

Try run: https://treeherder.mozilla.org/jobs?repo=try&revision=603395f855df6a69fe1feb0826ebeab81f26235c

The oranges there look like known intermittents, so I've gone ahead and triggered autoland.

Pushed by dholbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/17985a7cd00e Remove checks for NS_COORD_IS_FLOAT, and its associated VERIFY_COORD() function. r=jrmuizel
Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → 100 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: