Fix panic trim_first_and_last_line_of_whitespace
on bad slice indices
#865
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes: #727
I believe this appropriately fixes the panic found in #727 where the end index would end up preceding the start.
If this doesn't match the expected behavior of the method then let me know. I didn't see any comments or example tests, so I was mostly just guessing at how it should behave for that case. It seemed like the condition checking for
self[i.saturating_sub(1)] == b'\r'
was to handle stripping off the fullb"\r\n"
, so I updated the condition to handle that case specificallyThe end index could also be out of the range of the slice too since it's fallback value is
self.len()
while the slicing uses an inclusive rangeI ended up adding a basic property-based test along with regression tests to be more confident in the implementation which is what ended up catching the case with end index's fallback value