Bug 138325 – Web Inspector: Fix RWIProtocol 64-to-32 bit conversion warnings

• Status: RESOLVED
• Resolution: FIXED
• Component: Web Inspector

[Joseph Pecoraro]

When building the ObjC Generated protocol files with warnings I see:

.../JavaScriptCore.framework/PrivateHeaders/InspectorValues.h:265:38: error: implicit conversion loses integer precision: 'size_t' (aka 'unsigned long') to 'unsigned int' [-Werror,-Wshorten-64-to-32]
.../DerivedSources/WebInspector/RWIProtocolBackendDispatchers.mm:397:58: error: implicit conversion loses integer precision: 'NSInteger' (aka 'long') to 'int' [-Werror,-Wshorten-64-to-32]
.../DerivedSources/WebInspector/RWIProtocolEventDispatchers.mm:109:62: error: implicit conversion loses integer precision: 'NSInteger' (aka 'long') to 'int' [-Werror,-Wshorten-64-to-32]
.../DerivedSources/WebInspector/RWIProtocolTypes.mm:70:23: error: implicit conversion loses integer precision: 'NSInteger' (aka 'long') to 'int' [-Werror,-Wshorten-64-to-32]

Instead of NSInteger for "integer" protocol types, we should just use "int" to match InspectorValue/InspectorObject's interface.
Note we can keep NS_ENUM(NSInteger) because those always get converted to/from WTF::Strings on the internal InspectorObject.

[Radar WebKit Bug Importer]

<rdar://problem/18857253>

[Joseph Pecoraro]

Created attachment 240873 [details]
[PATCH] Proposed Fix

[Joseph Pecoraro]

Oops, I forgot to add script tests rebaselines.

[WebKit Commit Bot]

This patch modifies the inspector protocol generator. Please ensure that you have rebaselined any generator test results (i.e., by running `Tools/Scripts/run-inspector-generator-tests --reset-results`)

[Joseph Pecoraro]

Created attachment 240874 [details]
[PATCH] Proposed Fix

[Timothy Hatcher]

Comment on attachment 240874 [details]
[PATCH] Proposed Fix

View in context: https://bugs.webkit.org/attachment.cgi?id=240874&action=review

> Source/JavaScriptCore/ChangeLog:14
> +        Use int instead of NSInteger for APIs that eventually map to
> +        InspectorObject's setInteger, which takes an int.

Feels like a step backwards. Can we fix InspectorObject's setInteger instead?

[Joseph Pecoraro]

(In reply to comment #6)
> Comment on attachment 240874 [details]
> [PATCH] Proposed Fix
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=240874&action=review
> 
> > Source/JavaScriptCore/ChangeLog:14
> > +        Use int instead of NSInteger for APIs that eventually map to
> > +        InspectorObject's setInteger, which takes an int.
> 
> Feels like a step backwards. Can we fix InspectorObject's setInteger instead?

If we changed setInteger to support NSInteger it likely be size_t.

However, there is a potential real issue here. These "int" values get JSON serialized, and JavaScript Integers can not be a full 64bit integer:

> JavaScript represents numbers using IEEE-754 double-precision (64 bit) format.
> As I understand it this gives you 53 bits precision

The compromise that the JSC JSValue API went with was using an explicit int32_t for creating a JSValue with an integer value. We could move our Internal APIs to that type, but I think just using int for now is fine.

[WebKit Commit Bot]

Comment on attachment 240874 [details]
[PATCH] Proposed Fix

Clearing flags on attachment: 240874

Committed r175493: <http://trac.webkit.org/changeset/175493>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.