-
Notifications
You must be signed in to change notification settings - Fork 12.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
library: core::str::lines: Fix handling of trailing bare CR #91191
Conversation
Sadly there doesn't seem to be a way to do this right now.
Currently, there is one bug demonstrated here. Signed-off-by: Ian Jackson <[email protected]>
E.g., split "bare\r" into the single line "bare\r", not "bare". The documentation for this function says that only LF or CR-LF count as newlines. So a bare CR is not a line ending, and must not be stripped. This fix is a behavioural change, even though it brings the behaviour into line with the documentation, and into line with that of `std::io::BufRead:;lines()`. It seems unlikely that anyone is relying on this bug, but I'm not sure how to rule it out. Perhaps this should have an FCP or a crater run or something. It should definitely be in the release notes. This is an alternative to rust-lang#91051, which proposes to document rather than fix the behaviour. As for the implementation: the current version doesn't give the map closure the right information, so we need to use split_inclusive. After that, we can reuse the logic in the new `str::trim_newline`. Signed-off-by: Ian Jackson <[email protected]>
r? @m-ou-se (rust-highfive has picked a reviewer for you, use r? to override) |
@rustbot modify labels +T-libs |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be happy to propose FCP to T-libs-api, but I would prefer not to bundle a new public trim_newline
method into this fix. Could that please be removed from this PR?
I had expected #91047 ( I'm not sure precisely why #91047 is stalled but if you prefer I can remove the |
☔ The latest upstream changes (presumably #90414) made this pull request unmergeable. Please resolve the merge conflicts. |
@ijackson whats the update on this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'll close this so that anyone else interested in resolving #94435 isn't deterred by there already being an old existing PR.
We'll need a PR that fixes the issue while exposing no novel standard library APIs.
…, r=joshtriplett Fix handling of trailing bare CR in str::lines Continuing from rust-lang#91191. Fixes rust-lang#94435.
…, r=ChrisDenton Fix handling of trailing bare CR in str::lines Continuing from rust-lang#91191. Fixes rust-lang#94435.
…, r=ChrisDenton Fix handling of trailing bare CR in str::lines Continuing from rust-lang#91191. Fixes rust-lang#94435.
E.g., split
"bare\r"
into the single line"bare\r"
, not"bare"
.The documentation for this function says that only LF or CR-LF count as newlines. So a bare CR is not a line ending, and must not be stripped.
This fix is a behavioural change, even though it brings the behaviour into line with the documentation, and into line with that of
std::io::BufRead:;lines()
.It seems unlikely that anyone is relying on this bug, but I'm not sure how to rule it out. Perhaps this should have an FCP or a crater run or something. It should definitely be in the release notes.
This is an alternative to #91051, which proposes to document rather than fix the behaviour.
Also add some tests of edge cases. I felt they were useful for the docs so I made them doctests.
As for the implementation: the current version doesn't give the map closure the right information, so we need to use
split_inclusive
. After that, we can reuse the logic in the newstr::trim_newline
.Currently that is not merged yet, so this branch is on top of #91047.