Continue with InlineBox float->LayoutUnit migration.

Source/core/rendering/FloatToLayoutUnit.h

Index: Source/core/rendering/FloatToLayoutUnit.h
diff --git a/Source/core/rendering/FloatToLayoutUnit.h b/Source/core/rendering/FloatToLayoutUnit.h
index 456139ef602ddcbb8ca44cb11349d3d84a5a5254..30a699d35e01d372a172a1a128fccd2bda10632a 100644
--- a/Source/core/rendering/FloatToLayoutUnit.h
+++ b/Source/core/rendering/FloatToLayoutUnit.h
@@ -23,8 +23,11 @@ using FloatSizeWillBeLayoutSize = LayoutSize;
 #define MINUS_ONE_LAYOUT_UNIT LayoutUnit(-1)
 
 #define LAYOUT_UNIT_TO_FLOAT(layoutUnit) (layoutUnit)
+#define WILL_BE_LAYOUT_UNIT_TO_FLOAT(layoutUnit) (layoutUnit.toFloat())

[leviw_travelin_and_unemployed, 2014/11/03 21:35:02]

These names don't actually seem self-identifying to me. LAYOUT_UNIT_TO_FLOAT and
WILL_BE_LAYOUT_UNIT_TO_FLOAT don't imply the actual difference.

It seems to me that you want a class to make this indirection not awful. With
the conversion to sub-pixel layout, we used LayoutUnit (originally an integer),
which you could optionally point at FractionalLayoutUnit (sub-pixel magic).

If you did that, it seems to me that you could have much more reasonable and
understandable conversions to other types. This model is hard to parse for me.

 #define LAYOUT_UNIT_CEIL(layoutUnit) (layoutUnit.ceil())
 #define INT_TO_LAYOUT_UNIT(i) (LayoutUnit(i))
+#define WILL_BE_LAYOUT_UNIT_TO_INT(layoutUnit) (layoutUnit.toInt())
+#define LAYOUT_UNIT_ROUND(layoutUnit) (layoutUnit.round())
 
 #else // ENABLE(LAYOUT_UNIT_IN_INLINE_BOXES)
 
@@ -41,8 +44,11 @@ using FloatSizeWillBeLayoutSize = FloatSize;
 #define MINUS_ONE_LAYOUT_UNIT -1
 
 #define LAYOUT_UNIT_TO_FLOAT(layoutUnit) (layoutUnit.toFloat())
+#define WILL_BE_LAYOUT_UNIT_TO_FLOAT(layoutUnit) (layoutUnit)
 #define LAYOUT_UNIT_CEIL(layoutUnit) (ceilf(layoutUnit))
 #define INT_TO_LAYOUT_UNIT(i) (i)
+#define WILL_BE_LAYOUT_UNIT_TO_INT(layoutUnit) (layoutUnit)
+#define LAYOUT_UNIT_ROUND(layoutUnit) (lroundf(layoutUnit))
 
 #endif // ENABLE(LAYOUT_UNIT_IN_INLINE_BOXES)