Integer parsing should accept leading plus

[arthurprs]

Closes#27580

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @alexcrichton (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. 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.

[hanna-kruppe]

Damn, I also had a patch for this and was only waiting for the local make check to pass. But mine made the minimal necessary changes and this is probably better, more coherent code, so no harm done.

[hanna-kruppe]

My personal preference would be to not check for empty inputs in the match. Instead I'd slice unconditionally and check if digits.is_empty() afterwards. Seems slightly simpler and shorter.

[arthurprs]

Great suggestion, I constantly abuse pattern matching...

[alexcrichton]

Thanks @arthurprs! This implementation looks fine to me, but it's a bit of a significant change to a core function in the standard library, so I'm going to tag this with T-libs to bring up for some broader discussion.

[alexcrichton]

cc @rust-lang/libs

[Gankra]

👍 this seems good

[hanna-kruppe]

Oh my! I just realized that my float rewrite require in #27307 made the analogous change for floats. Compare the output of this code on stable (1.3, branched before the PR was merged) and nightly. I didn't even realize at the time that this was a change of behavior (even though I encountered and worked around the integer version of it), and neither did any of the reviewers — or if they noticed, they didn't mind.

[BurntSushi]

Are there any downsides to permitting +?

[alexcrichton]

Nah it seems fine to me, just something to consider and make an explicit decision about! Although given the change @rkruppe mentioned it may already be decided :)

[alexcrichton]

This libs team discussed this yesterday and the conclusion was to merge. This fits a well accepted precedent from other languages and custom parsing of other formats typically have their own parser anyway so it's unlikely that changes here will affect that form of robust parsers.

Thanks for the PR @arthurprs!

@bors: r+ 123a833

[bors]

⌛ Testing commit 123a833 with merge 64c4b51...

[aturon]

I'm adding to relnotes, and we should advertise this change widely when it lands since it's a visible behavioral change.

[alexcrichton]

Oh right, excellent idea!

[bors]

☀️ Test successful - auto-linux-32-nopt-t, auto-linux-32-opt, auto-linux-64-nopt-t, auto-linux-64-opt, auto-linux-64-x-android-t, auto-mac-32-opt, auto-mac-64-nopt-t, auto-mac-64-opt, auto-win-gnu-32-nopt-t, auto-win-gnu-32-opt, auto-win-gnu-64-nopt-t, auto-win-gnu-64-opt, auto-win-msvc-32-opt, auto-win-msvc-64-opt