Constify conversion traits

[clarfonthey]

Tracking issue: #143773

Note that this renames the feature from const_from to const_convert. Several impls were wrongly included under const_try and those have been moved appropriately.

Feature includes the constification of the following traits:

• From
• Into
• TryFrom
• TryInto
• AsRef
• AsMut
• Borrow
• BorrowMut
• Deref
• DerefMut

Note that Deref and DerefMut are currently listed under the now-closed #88955, but I decided it's worth just including that here instead. Since these all end up being needed for each other, it's best to bundle them all together, even though the semantics are different.

There are a few methods that are intrinsically tied to these traits which I've included in the feature. Particularly, those which are wrappers over AsRef:

• ByteStr::new (unstable under bstr feature)
• OsStr::new
• Path::new

Those which directly use Into:

• Result::into_ok
• Result::into_err

And those which use Deref and DerefMut:

• Pin::as_ref
• Pin::as_mut
• Pin::as_deref_mut

There are a few methods which were not const-stable before, but are used in the constification of these methods or tangential to them. I added them under a separate feature, const_convert_methods, and filed them under #144288. They are:

• CStr::as_bytes (existing method, now const)
• CStr::as_bytes_with_nul (existing method, now const)
• CStr::as_c_str (existing method, now const)
• OsString::as_os_str (existing method, now const)
• PathBuf::as_path (existing method, now const)
• path::{Component, PrefixComponent}::as_os_str (existing method, now const)

Additionally, rust-lang/libs-team#624 proposes adding the following methods, which are added by this PR but marked private:

• OsString::as_mut_os_str (new method; DerefMut implementation exists)
• PathBuf::as_mut_path (new method; DerefMut implementation exists)

I've checked through the list in rustdoc to make sure I got all the important stuff, but here's what I missed:

• VaList (unfinished, unstable)
• Collections' helper stuff (no const heap, not worth it)
• Sync primitives (could ignore the mutexes in const context, not going to)
• path::{Components, Iter} (derive_const(Clone) needs some work, didn't feel like it)
• Slice iterators (requires const ptr::addr; probably fixed by Make slice iterators carry only a single provenance #122971)
• SIMD types (will do later; see Constified SIMD portable-simd#467)
• Various heap-allocating (or heap-allocated) conversions
• A few system-specific types

I tried to do the heap-allocated conversions that don't technically require reallocating, like PathBuf <-> OsString, but quickly realised that due to the way const Destruct works, I would have to replace all of them with versions that go via ManuallyDrop, and decided to hold off for now.

[rustbot]

r? @tgross35

rustbot has assigned @tgross35.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[tgross35]

Cc @rust-lang/wg-const-eval @rust-lang/libs-api

There are a few methods which were not const-stable before, but are used in the constification of these methods or tangential to them. I added them under a separate feature, const_convert_methods, and filed them under #144288. They are:

* `CStr::as_bytes` (existing method, now const)
* `CStr::as_bytes_with_nul` (existing method, now const)
* `CStr::as_c_str` (existing method, now const)
* `CStr::as_mut_c_str` (new method; `DerefMut` implementation does not exist)
* `OsString::as_os_str` (existing method, now const)
* `OsString::as_mut_os_str` (new method; `DerefMut` implementation exists)
* `PathBuf::as_path` (existing method, now const)
* `PathBuf::as_mut_path` (new method; `DerefMut` implementation exists)
* `path::{Component, PrefixComponent}::as_os_str` (existing method, now const)

Adding these new methods seems orthogonal and needs an ACP (or libs-api signoff). Could it be split to a separate PR to be discussed independently?

const_try -> const_convert could optionally also be split off, to make this PR specifically about behavior that is new.

[clarfonthey]

I guess I could split this PR into several parts; my main justification was that all the new additions are unstable and if they were not accepted, could be kept that way and potentially left unstable.

I figured it'd be better to just mark the methods as unstably const and leave them that way, than work around that to leave the code in an undesirable state just to avoid having to run extra votes.

[clarfonthey]

Also to clarify what I mean by leaving the code in a worse state: I could make a bunch of private methods with the same functionality and then update the stable ones to use that, thus sidestepping the bureaucracy of adding constness to existing API which is in libs-api' domain.

or

I could just mark these methods as unstably const or outright unstable knowing that they are very similar to existing methods, but still leave them open to libs-api to discuss in a dedicated forum, as I have.

The issue here is, I know that whenever I submit a dedicated libs-api PR, I risk months of things not even being noticed, because there are several people in that review pool who seemingly do not actually review PRs. So, rather than doing things via hacky private methods, or waiting on libs-api to actually review these methods separately, I just tack them on this PR and let libs-api review them at their own pace. Knowing that they're all unstable anyway, since this isn't actually affecting a stable API.

[RalfJung]

Nothing here does anything interesting const-wise, right? No new intrinsics or anything like that?

This is entirely up to t-libs-api then, as far as I am concerned.

It's not clear to me why these new methods were added (why does the old implementation of DerefMut for OsString not just work in const?), but using an omnibus PR to bypass the ACP process is definitely not appropriate. ACPs don't get assigned a single reviewer, they get team-nominated, so your point regarding the review pool makes no sense in this context. In fact, there is no such thing as a "libs-api review pool", only a libs review pool defined here, and AFAIK everyone there is active. And finally, if a PR doesn't get reviewed in 2 weeks, you can ask for a re-toll of the reviewer, you clearly know your way around the Rust project well enough to ping some appropriate reviewer. So nothing would get stuck for months.

I know things taking a week or three to land can be frustrating, but please be mindful that many reviewers are volunteers, and trying to bypass processes is more harmful than helpful for the project as a whole. If a process is broken, it needs to be fixed. For tiny additions such as new public methods on existing types, all signs I am aware of indicate that the ACP process works just fine.

[clarfonthey]

You're right that I'm combining just adding constness to things with making them into actual public methods. I'll close this for now and open a few separate PRs + an ACP.

[clarfonthey]

Also, to fully clarify: the main issue here is the addition of the new methods. It has generally been okay to just mark some methods as const-unstable without an ACP, since the methods were already accepted, just not in const context.

I'll resubmit this PR in a modified form once I'm feeling in a less venty mood. Sorry for not being entirely clear here and trying to bypass some bureaucracy. ACPs are still important.

[RalfJung]

Also, to fully clarify: the main issue here is the addition of the new methods. It has generally been okay to just mark some methods as const-unstable without an ACP, since the methods were already accepted, just not in const context.

Yes, new unstable methods need ACP, new unstable constness does not.

[clarfonthey]

Okay, after spending more time to reflect, the changes I need to make to this PR are actually pretty small and I just marked the methods as private instead of unstable. Apologies for trying to bypass procedure: I understand why it's there, but sometimes when I get frustrated by things I get a bit overzealous.

I can still split up the PR into the parts doing different things if you want (adding unstable constness, changing features for impls, and adding the impls) but it felt all related enough that it should go together and be reviewed by the same person. For now though, I'll at least reopen until we make that decision. (assuming that rustbot/bors can handle it…)