(#102929) Implement String:leak

[finnbear]

Implementation of String::leak (#102929)

ACP: rust-lang/libs-team#109

Superseded by: #103280

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon.

Please see the contribution instructions for more information.

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[finnbear]

@rustbot label +T-libs-api -T-libs

[m-ou-se]

Is there any reason to use a generic <'a> instead of just 'static here? I believe the only reason we use <'a> for Vec<T> is for situations where T: !'static.

Suggested change

	pub fn leak<'a>(self) -> &'a mut str {
	pub fn leak(self) -> &'static mut str {

[finnbear]

Good idea; as I understand it, variance will still allow the 'static to be used for any 'a

[finnbear]

Actually, I think there is another reason. Vec is generic over A: Allocator and this may apply to String in the future. At that point, the generic lifetime would be bounded by that of the allocator. I don't know if adding the generic lifetime later would be a breaking change. Thoughts?

[klensy]

https://rustc-dev-guide.rust-lang.org/git.html#no-merge-policy you can squash commits.

[finnbear]

In an attempt to undo the merge commit, I messed up git beyond my ability to repair it, so this PR is superseded by #103280

[rust-log-analyzer]

The job x86_64-gnu-llvm-13 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

error: make failed
status: exit status: 2
command: "make"
--- stdout -------------------------------
LD_LIBRARY_PATH="/checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make-fulldeps/alloc-no-oom-handling/alloc-no-oom-handling:/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0-bootstrap-tools/x86_64-unknown-linux-gnu/release/deps:/checkout/obj/build/x86_64-unknown-linux-gnu/stage0/lib" '/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/bin/rustc' --out-dir /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make-fulldeps/alloc-no-oom-handling/alloc-no-oom-handling -L /checkout/obj/build/x86_64-unknown-linux-gnu/test/run-make-fulldeps/alloc-no-oom-handling/alloc-no-oom-handling  --edition=2021 -Dwarnings --crate-type=rlib ../../../../library/alloc/src/lib.rs --cfg no_global_oom_handling
--- stderr -------------------------------
error[E0425]: cannot find function `from_utf8_unchecked_mut` in this scope
    --> ../../../../library/alloc/src/string.rs:1879:18
     |
     |
1879 |         unsafe { from_utf8_unchecked_mut(slice) }
     |
help: consider importing one of these items
     |
47   | use core::str::from_utf8_unchecked_mut;