Remove some panics from zerovec's derive and icu_codepointtrie #6052
Conversation
Manishearth
changed the title
|
The zerovec one seems like a slam dunk to me. The codepointtrie one is iffy: it would be nice to have these panics as debug checks at least. Most Rust release builds do not panic on overflow, however Android does. We could in theory disable that behavior for the bionic binary, but I don't know if it's easy. It is nice to make an attempt to remove panics from this code. On the other hand, it makes the code gnarlier, and bugs will be harder to trace. (I could introduce some code that wraps the wrapping arithmetic in debug assertions) Routes to take here:
We could also potentially add CI ensuring that panicking infra never makes it into bionic. |
Manishearth
force-pushed
the
rmpanic
branch
3 times, most recently
from
2073a5d to
6df2f3a
Compare
| @@ -414,7 +414,9 @@ fn make_encode_impl( | |||
| let ty = &field.field.ty; | |||
| let accessor = &field.accessor; | |||
| quote!( | |||
| #[allow(clippy::indexing_slicing)] // generate_per_field_offsets produces valid indices | |||
| // generate_per_field_offsets produces valid indices, | |||
| // and we don't care about panics in Encode impls | |||
There was a problem hiding this comment.
Well, human-readable deserialize for some VarULE types involves using EncodeAsVarULE.
Do we care about no-panic in JSON runtime mode?
There was a problem hiding this comment.
No, we already have panics in Encode impls
utils/zerovec/derive/src/varule.rs
Outdated
| @@ -108,16 +108,17 @@ pub fn derive_impl( | |||
| } | |||
| #validators | |||
| debug_assert_eq!(#remaining_offset, #ule_size); | |||
There was a problem hiding this comment.
Nit: Since we are using unsafe, a debug_assert is not generally sufficient; this is easy to fix though since we are in a fallible function, though. Just change the debug_assert_eq to something that returns a UleError.
There was a problem hiding this comment.
It's fine in this case because the debug assert is double-checking something that is already known to be true. The length check that is relevant is the one before this, but I realized I could refactor this to remove unsafe by combining the indexing with the length check
There was a problem hiding this comment.
And while I was there I found something else to improve
| let mut index1_pos: u32 = code_point >> SHIFT_1; | ||
| if self.header.trie_type == TrieType::Fast { | ||
| debug_assert!( | ||
| FAST_TYPE_FAST_INDEXING_MAX < code_point && code_point < self.header.high_start | ||
| ); | ||
| index1_pos = index1_pos + BMP_INDEX_LENGTH - OMITTED_BMP_INDEX_1_LENGTH; | ||
| index1_pos = index1_pos.wrapping_add(BMP_INDEX_LENGTH - OMITTED_BMP_INDEX_1_LENGTH); |
There was a problem hiding this comment.
Suggestion: Given that we have a good GIGO code path, I agree with removing the panicky subtract impls in "safe release" mode like Android is using. However, I think we should keep the debug asserts in test mode. In other words, since we do this a lot in this file, please make a helper function or macro that does the wrapping_add or wrapping_sub with an explicit debug_assert and use it everywhere in this file.
The helper function/macro could eventually make its way into the shared-macro helper file. (#4467)
|
I prefer this option conditional on the "potentially" part:
|
|
Works for me, happy to add debug assertions |
|
I managed to have a nice-looking but simple macro; and I also discovered another place in zerovec derive that could use a non-panicking bounds check. |
Discovered whilst working on bionic, I noticed panic machinery being pulled in.