0.94.x str substring regression with negative end-offset #13077
Description
Describe the bug
I had a long-running process that was still running under my previous 0.93 release that I just stopped and reloaded in 0.94.2 where it promptly crashed. I've isolated the problem to str substring no longer properly handling negative offsets from the end of a string.
How to reproduce
> "apples" | str substring 0..(-1)
> ("apples" | str substring 0..(-1)) == ''
trueExpected behavior
Retest under 0.93, and this worked as expected:
> "apples" | str substring 0..(-1)
appleScreenshots
No response
Configuration
| key | value |
|---|---|
| version | 0.94.2 |
| major | 0 |
| minor | 94 |
| patch | 2 |
| branch | |
| commit_hash | |
| build_os | linux-x86_64 |
| build_target | x86_64-unknown-linux-gnu |
| rust_version | rustc 1.77.2 (25ef9e3d8 2024-04-09) |
| rust_channel | stable-x86_64-unknown-linux-gnu |
| cargo_version | cargo 1.77.2 (e52e36006 2024-03-26) |
| build_time | 2024-06-06 01:29:43 -04:00 |
| build_rust_channel | release |
| allocator | mimalloc |
| features | default, sqlite, system-clipboard, trash, which |
| installed_plugins |
Additional context
(-2) as the end-offset now works like (-1) used to under 0.93.
> "apples" | str substring 0..(-2)
applecc @WindSoilder - I've bisected this to #12894. I don't see any mention of negative offsets in that PR. Was this an intentional part of the change or no?
It seems to me that -1 more accurately reflects "one character before the end of the string" in a slicing operation? It also seems to me that using an end-offset of -1 shouldn't result in an empty string?
Related (and starting to understand the "consistency" issues a bit ...):
> [ 1 2 3 4 ] | range 0..(-1)
[ 1 2 3 4 ]
> [ 1 2 3 4 ] | range 0..(-2)
[ 1 2 3 ]^ In this case, at least -1 doesn't result in an empty list, but I'd still expect the -1 offset to be more "typical" slicing, right?