Uh oh!
There was an error while loading. Please reload this page.
Add Utf8Error::error_len, to help incremental and/or lossy decoding. - #40212
Conversation
rust-highfive
commented
Mar 2, 2017
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @sfackler (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
SimonSapin
commented
Mar 2, 2017
This is a new standard library public API that I’m hoping to stabilize eventually. But it’s a small extension of an existing feature rather than an entirely new feature, so it seemed appropriate to submit without an RFC. |
sfackler
commented
Mar 2, 2017
This seems reasonable to me and I agree that an RFC isn't necessary. cc @rust-lang/libs @rfcbot fcp merge |
Team member @sfackler has proposed to merge this. The next step is review by the rest of the tagged teams: No concerns currently listed. Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See this document for info about what commands tagged team members can give me. |
bors
commented
Mar 3, 2017
☔ The latest upstream changes (presumably #40189) made this pull request unmergeable. Please resolve the merge conflicts. |
3e1601a to
7e95d5bCompareSimonSapin
commented
Mar 3, 2017
Rebased. |
5ea9b0e to
354f092CompareSimonSapin
commented
Mar 6, 2017
After trying it I’ve pushed another commit to change the proposed API:
re r? @BurntSushi@Kimundi@alexcrichton@aturon@brson@sfackler |
alexcrichton
commented
Mar 7, 2017
Seems fine by me! |
aturon
commented
Mar 13, 2017
@bors: r+ |
bors
commented
Mar 13, 2017
📌 Commit 354f092 has been approved by |
SimonSapin
commented
Mar 13, 2017
Added a tracking issue number to the PR. @aturon re-r? |
alexcrichton
commented
Mar 13, 2017
@bors: r=aturon |
bors
commented
Mar 13, 2017
📌 Commit 5b3dbd8 has been approved by |
bors
commented
Mar 14, 2017
🔒 Merge conflict |
Without this, code outside of the standard library needs to reimplement most of the logic `from_utf8` to interpret the bytes after `valid_up_to()`.
Their relationship is: * `resume_from = error_len.map(|l| l + valid_up_to)` * error_len is always one of None, Some(1), Some(2), or Some(3). When I started using resume_from I almost always ended up subtracting valid_up_to to obtain error_len. Therefore the latter is what should be provided in the first place.
5b3dbd8 to
73370c5CompareSimonSapin
commented
Mar 14, 2017
Rebased. I don’t understand how this happened, but git seemed convinced that my commits wanted to remove the @aturon or @alexcrichton r? |
~submodules~ @bors: r=aturon |
bors
commented
Mar 14, 2017
📌 Commit 73370c5 has been approved by |
bors
commented
Mar 14, 2017
💡 This pull request was already approved, no need to approve it again.
|
bors
commented
Mar 14, 2017
📌 Commit 73370c5 has been approved by |
bors
commented
Mar 14, 2017
⌛ Testing commit 73370c5 with merge ae118b1... |
frewsxcv
commented
Mar 15, 2017
@bors retry |
bors
commented
Mar 15, 2017
Add Utf8Error::error_len, to help incremental and/or lossy decoding. Without this, code outside of the standard library needs to reimplement most of the logic `from_utf8` to interpret the bytes after `valid_up_to()`.
bors
commented
Mar 15, 2017
☀️ Test successful - status-appveyor, status-travis |
Without this, code outside of the standard library needs to reimplement most of the logic
from_utf8to interpret the bytes aftervalid_up_to().