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.
<rdar://problem/18857253>
Created attachment 240873 [details] [PATCH] Proposed Fix
Oops, I forgot to add script tests rebaselines.
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`)
Created attachment 240874 [details] [PATCH] Proposed Fix
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?
(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.
Comment on attachment 240874 [details] [PATCH] Proposed Fix Clearing flags on attachment: 240874 Committed r175493: <http://trac.webkit.org/changeset/175493>
All reviewed patches have been landed. Closing bug.