Hide allocator details from TryReserveError

[kornelski]

I think there's no need for TryReserveError to carry detailed information, but I wouldn't want that issue to delay stabilization of the try_reserve feature.

So I'm proposing to stabilize try_reserve with a TryReserveError as an opaque structure, and if needed, expose error details later.

This PR moves the enum to an unstable inner TryReserveErrorKind that lives under a separate feature flag. TryReserveErrorKind could possibly be left as an implementation detail forever, and the TryReserveError get methods such as allocation_size() -> Option<usize> or layout() -> Option<Layout> instead, or the details could be dropped completely to make try-reserve errors just a unit struct, and thus smaller and cheaper.

[rust-highfive]

r? @kennytm

(rust-highfive has picked a reviewer for you, use r? to override)

[kennytm]

🤔 i'll defer this to T-libs-api to consider.

r? @rust-lang/libs-api

[yaahc]

I don't love how every match against a TryReserveError needs an explicit map_err to get the kind now before matching, but as far as I can tell it wouldn't be backwards incompatible to switch the opaque struct back to an enum in the future to enable direct convenient matching once we're confident we know the representation we want internally.

+1 from me but I'll wait until after today's libs-api team meeting before approving since it's already nominated.

[yaahc]

Everyone seemed amenable to this change in the libs-api meeting, though we didn't go into a particularly detailed discussion about it. The expectation being that such a discussion would happen during follow up stabilization discussions.

@bors r+

[bors]

📌 Commit a294aa8 has been approved by yaahc

[bors]

⌛ Testing commit a294aa8 with merge 996ff2e...

[bors]

☀️ Test successful - checks-actions
Approved by: yaahc
Pushing 996ff2e to master...

[pnkfelix]

Just a quick heads up: For some reason, this PR seems to have regressed the html5ever-opt benchmark: 4.24% more instructions:u, and 8.16% more max-rss.

I'm not sure why this PR would cause that change, and it seems somewhat isolated to html5ever-opt. Skimming over the max-rss graphs, we cna see that html5-ever-opt is somewhat noisy, but it seems like a ~5% bump in max-rss can be potentially attributed to this PR.

(At the same time, it isn't a broad regression across many benchmarks. So it probably isn't worth investing much time looking into this. I just wanted to post a heads up.)

[the8472]

#87843 might address the regression.