Adjust RawPropsPropNameLength's type to account for increased number of props#39008
Adjust RawPropsPropNameLength's type to account for increased number of props#39008vincentriemer wants to merge 1 commit intofacebook:mainfrom
Conversation
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
07c3152 to
0485cab
Compare
Base commit: b012027 |
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
0485cab to
b593b85
Compare
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
b593b85 to
778def8
Compare
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
778def8 to
35fbe20
Compare
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
35fbe20 to
411c6c2
Compare
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
411c6c2 to
3dfb5d1
Compare
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
3dfb5d1 to
ff4c41e
Compare
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
ff4c41e to
ed51fe1
Compare
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
ed51fe1 to
0a993a3
Compare
|
This pull request was exported from Phabricator. Differential Revision: D48331909 |
…of props (facebook#39008) Summary: Pull Request resolved: facebook#39008 Changelog: [Internal] - Adjust RawPropsPropNameLength's type to account for increased number of props While investigating why we needed to back out D48288752 I discovered that the root cause was that the `items_` vector in `RawProsKeyMap` was now a size greater than 255 which becomes an issue because `items_`'s indices are statically cast to `RawPropsPropNameLength` (previously alias to `uint8_t`). This diff updates `RawPropsPropNameLength` to be an alias to `uint16_t` so the current issue is resolved as well as adding an assert to ensure (however unlikely) that this happens again. Reviewed By: rozele Differential Revision: D48331909 fbshipit-source-id: 86a2b67bdf5090616252e9eea9165e7752793bc1
0a993a3 to
ceb024a
Compare
|
This pull request was successfully merged by @vincentriemer in 894b883. When will my fix make it into a release? | Upcoming Releases |
|
This pull request has been merged in 894b883. |
…of props (#39008) Summary: Pull Request resolved: #39008 Changelog: [Internal] - Adjust RawPropsPropNameLength's type to account for increased number of props While investigating why we needed to back out D48288752 I discovered that the root cause was that the `items_` vector in `RawProsKeyMap` was now a size greater than 255 which becomes an issue because `items_`'s indices are statically cast to `RawPropsPropNameLength` (previously alias to `uint8_t`). This diff updates `RawPropsPropNameLength` to be an alias to `uint16_t` so the current issue is resolved as well as adding an assert to ensure (however unlikely) that this happens again. Reviewed By: rozele Differential Revision: D48331909 fbshipit-source-id: f6bc3e4825f2f293d79d8cd90c40ced7cba0e3c5
Summary:
Changelog: [Internal] - Adjust RawPropsPropNameLength's type to account for increased number of props
While investigating why we needed to back out D48288752 I discovered that the root cause was that the
items_vector inRawProsKeyMapwas now a size greater than 255 which becomes an issue becauseitems_'s indices are statically cast toRawPropsPropNameLength(previously alias touint8_t).This diff updates
RawPropsPropNameLengthto be an alias touint16_tso the current issue is resolved as well as adding an assert to ensure (however unlikely) that this happens again.Differential Revision: D48331909