I am not entirely sure what's going on here, so I'll explain how this was found. 1. In bug 1645896, we added a case to a switch block[1] that was comparing a uint32_t value to various nsIWebProgressListener state constants[2], which are all defined as const unsigned long. 2. The newly added case was for a state constant with value 0x80000000. 3. This caused build failure on Windows, with the compiler complaining `error: case value evaluates to -2147483648, which cannot be narrowed to type 'uint32_t' (aka 'unsigned int') [-Wc++11-narrowing]` [3] 4. It appears that the internal type of the enum generated by the XPIDL parser does _not_ end up being an unsigned int type on Windows, though the literals are suffixed with "U"[4] at least on whatever platform searchfox indexes generated files for. I'm quite terrible at C++ so I'm not sure if this is a bug but it sure sounds like one. Should the XPIDL parser be emitting `: unsigned long` on the enum declaration? There are three other instances of `const unsigned long` values of `0x80000000` in m-c at the time of writing this[5] but they seem unused, so maybe that's why this hasn't come up before. FWIW, if indeed this is a bug, I'd be interested in working on this (as a learning exercise) if the fix isn't too complex. [1] https://phabricator.services.mozilla.com/D80675 [2] https://searchfox.org/mozilla-central/rev/a87a1c3b543475276e6d57a7a80cb02f3e42b6ed/uriloader/base/nsIWebProgressListener.idl#336-354 [3] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307352680&repo=autoland&lineNumber=33354 [4] https://searchfox.org/mozilla-central/source/__GENERATED__/dist/include/nsIWebProgressListener.h#77 [5] https://searchfox.org/mozilla-central/search?q=0x80000000&path=.idl
Bug 1648346 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I am not entirely sure what's going on here, so I'll explain how this was found. 1. In bug 1645896, we added a case to a switch block[1] that was comparing a uint32_t value to various nsIWebProgressListener state constants[2], which are all defined as const unsigned long. 2. The newly added case was for a state constant with value 0x80000000. 3. This caused build failure on Windows, with the compiler complaining `error: case value evaluates to -2147483648, which cannot be narrowed to type 'uint32_t' (aka 'unsigned int') [-Wc++11-narrowing]` [3] 4. It appears that the internal type of the enum generated by the XPIDL parser does _not_ end up being an unsigned int type on Windows, though the literals are suffixed with "U"[4] at least on whatever platform searchfox indexes generated files for. I'm quite terrible at C++ so I'm not sure if this is a bug but it sure sounds like one. Should the XPIDL codegen be emitting `: unsigned long` on the enum declaration? There are three other instances of `const unsigned long` values of `0x80000000` in m-c at the time of writing this[5] but they seem unused, so maybe that's why this hasn't come up before. FWIW, if indeed this is a bug, I'd be interested in working on this (as a learning exercise) if the fix isn't too complex. [1] https://phabricator.services.mozilla.com/D80675 [2] https://searchfox.org/mozilla-central/rev/a87a1c3b543475276e6d57a7a80cb02f3e42b6ed/uriloader/base/nsIWebProgressListener.idl#336-354 [3] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307352680&repo=autoland&lineNumber=33354 [4] https://searchfox.org/mozilla-central/source/__GENERATED__/dist/include/nsIWebProgressListener.h#77 [5] https://searchfox.org/mozilla-central/search?q=0x80000000&path=.idl
I am not entirely sure what's going on here, so I'll explain how this was found. 1. In bug 1645896, we added a case to a switch block[1] that was comparing a uint32_t value to various nsIWebProgressListener state constants[2], which are all defined as const unsigned long. 2. The newly added case was for a state constant with value 0x80000000. 3. This caused build failure on Windows, with the compiler complaining `error: case value evaluates to -2147483648, which cannot be narrowed to type 'uint32_t' (aka 'unsigned int') [-Wc++11-narrowing]` [3] 4. It appears that the internal type of the enum generated by the XPIDL codegen does _not_ end up being an unsigned int type on Windows, though the literals are suffixed with "U"[4] at least on whatever platform searchfox indexes generated files for. I'm quite terrible at C++ so I'm not sure if this is a bug but it sure sounds like one. Should the XPIDL codegen be emitting `: unsigned long` on the enum declaration? There are three other instances of `const unsigned long` values of `0x80000000` in m-c at the time of writing this[5] but they seem unused, so maybe that's why this hasn't come up before. FWIW, if indeed this is a bug, I'd be interested in working on this (as a learning exercise) if the fix isn't too complex. [1] https://phabricator.services.mozilla.com/D80675 [2] https://searchfox.org/mozilla-central/rev/a87a1c3b543475276e6d57a7a80cb02f3e42b6ed/uriloader/base/nsIWebProgressListener.idl#336-354 [3] https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=307352680&repo=autoland&lineNumber=33354 [4] https://searchfox.org/mozilla-central/source/__GENERATED__/dist/include/nsIWebProgressListener.h#77 [5] https://searchfox.org/mozilla-central/search?q=0x80000000&path=.idl