alloc: add some try_* methods Rust-for-Linux needs #86938

Ericson2314 · 2021-07-07T14:25:58Z

Based off of Rust-for-Linux/linux@487d757

I also added a second commit to dedup the code using the new try_ ones in the old infallible ones.
I hope this doesn't cause performance issues, but I am not sure.

I didn't yet dedup the specialization traits, simply because I am less familiar with them. If that is desired, I'll do it too.

CC @joshtriplett @TimDiekmann

rust-highfive · 2021-07-07T14:26:01Z

r? @Mark-Simulacrum

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

library/alloc/src/slice.rs

Ericson2314 · 2021-07-07T14:27:54Z

library/alloc/src/collections/mod.rs

+    /// Panic, or worse, according to the global handlers for each case.
+    pub(crate) fn handle(self) -> ! {


It might be useful to expose this outside the crate, but I didn't get into that for now.

Ericson2314 · 2021-07-07T14:29:14Z

library/alloc/src/raw_vec.rs

+        match Self::try_allocate_in(capacity, init, alloc) {
+            Ok(r) => r,
+            Err(e) => e.handle(),
+        }


I saw some comment about unwrap_or_else slowing doing the LLVM portion of compilation so I didn't use it, but if that is no longer the case I am happy to change these.

library/alloc/src/raw_vec.rs

joshtriplett · 2021-07-07T14:50:39Z

For the file-length tidy check, I'd suggest just adding // ignore-tidy-filelength for now.

joshtriplett · 2021-07-07T14:51:17Z

Once this passes CI, we can do a try build and a perf run, to see if deduplicating the non-try methods causes a noticeable performance impact.

the8472 · 2021-07-07T22:18:20Z

Once this passes CI, we can do a try build and a perf run, to see if deduplicating the non-try methods causes a noticeable performance impact.

It looks like these will change both inlining and where the panic is called. In the past Vec code has been quite sensitive even to minor perturbations in this area. This is going to be interesting.

Ericson2314 · 2021-07-07T22:37:24Z

It's stuff like this that makes me wish one could #[inline_always] f(x) a specific call even if a function isn't normally inlined.

Mark-Simulacrum · 2021-07-11T14:50:48Z

@bors try @rust-timer queue

rust-timer · 2021-07-11T14:50:49Z

Awaiting bors try build completion.

@rustbot label: +S-waiting-on-perf

bors · 2021-07-11T14:51:13Z

⌛ Trying commit fa2063bc810fab690f0f7d76dbd12ffa8a70e6f6 with merge 27957d81236ab9a355af3d1636314f8272e8ab11...

Ericson2314 · 2021-07-11T14:56:59Z

Huh I thought i ran the formatter. Will fix and rebase.

In preparation for enabling `no_global_oom_handling` for `alloc`, we need to add some new methods. They are all marked as: #[stable(feature = "kernel", since = "1.0.0")] for easy identification. Signed-off-by: Miguel Ojeda <ojeda@kernel.org>

Mark-Simulacrum · 2021-07-14T15:06:21Z

@rust-timer build 27957d81236ab9a355af3d1636314f8272e8ab11

JohnCSimon · 2021-07-31T20:42:18Z

ping from triage:
@Ericson2314 can you please address the build failures?

bors · 2021-08-07T04:36:04Z

☔ The latest upstream changes (presumably #87408) made this pull request unmergeable. Please resolve the merge conflicts.

JohnCSimon · 2021-08-22T04:49:15Z

ping again from triage:
@Ericson2314 can you please address the build failures?

JohnCSimon · 2021-09-27T06:12:46Z

ping from triage:
@Ericson2314 there are still build failures

JohnCSimon · 2021-10-19T03:34:20Z

ping again from triage:
@Ericson2314 there are still build failures, after you've addressed them, can you set S-waiting-on-review?

Based off of Rust-for-Linux/linux@487d757

I did all the non-specialization trait ones. I hope this doesn't cause performance issues

rust-log-analyzer · 2021-10-19T15:17:45Z

The job mingw-check failed! Check out the build log: (web) (plain)

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

    Checking alloc v0.0.0 (/checkout/library/alloc)
    Checking cfg-if v0.1.10
    Checking adler v0.2.3
    Checking rustc-demangle v0.1.21
error[E0433]: failed to resolve: use of undeclared type `TryReserveErrorKind`
    |
    |
245 |             Err(_) => return Err(TryReserveErrorKind::AllocError { layout, non_exhaustive: () }),
    |                                  ^^^^^^^^^^^^^^^^^^^ use of undeclared type `TryReserveErrorKind`

error[E0433]: failed to resolve: use of undeclared type `TryReserveErrorKind`
     |
     |
1218 |             .map_err(|_| TryReserveErrorKind::AllocError { layout, non_exhaustive: () })
     |                          ^^^^^^^^^^^^^^^^^^^ use of undeclared type `TryReserveErrorKind`

error[E0433]: failed to resolve: use of undeclared type `TryReserveErrorKind`
    |
    |
105 |             Err(TryReserveErrorKind::CapacityOverflow)
    |                 ^^^^^^^^^^^^^^^^^^^ use of undeclared type `TryReserveErrorKind`
error[E0308]: mismatched types
   --> library/alloc/src/collections/mod.rs:117:13
    |
92  |     CapacityOverflow,
92  |     CapacityOverflow,
    |     ---------------- unit variant defined here
...
116 |         match self {
    |               ---- this expression has type `TryReserveError`
117 |             TryReserveErrorKind::CapacityOverflow => capacity_overflow(),
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `TryReserveError`, found enum `TryReserveErrorKind`
    |
help: you might have meant to use field `kind` whose type is `TryReserveErrorKind`
116 |         match self.kind {
    |               ~~~~~~~~~

error[E0308]: mismatched types
error[E0308]: mismatched types
   --> library/alloc/src/collections/mod.rs:118:13
    |
116 |         match self {
    |               ---- this expression has type `TryReserveError`
117 |             TryReserveErrorKind::CapacityOverflow => capacity_overflow(),
118 |             TryReserveErrorKind::AllocError { layout, non_exhaustive: () } => {
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected struct `TryReserveError`, found enum `TryReserveErrorKind`
    |
help: you might have meant to use field `kind` whose type is `TryReserveErrorKind`
116 |         match self.kind {
    |               ~~~~~~~~~


error[E0277]: the trait bound `TryReserveError: From<core::alloc::LayoutError>` is not satisfied
    |
    |
237 |         let layout = Layout::array::<T>(capacity)?;
    |                                                  ^ the trait `From<core::alloc::LayoutError>` is not implemented for `TryReserveError`
    = help: the following implementations were found:
    = help: the following implementations were found:
              <TryReserveError as From<TryReserveErrorKind>>
    = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, core::alloc::LayoutError>>` for `Result<RawVec<T, A>, TryReserveError>`
note: required by `from_residual`
    |
    |
339 |     fn from_residual(residual: R) -> Self;


error[E0277]: the trait bound `TryReserveError: From<core::alloc::LayoutError>` is not satisfied
     |
     |
1212 |             let layout = Layout::array::<T>(len)?;
     |                                                 ^ the trait `From<core::alloc::LayoutError>` is not implemented for `TryReserveError`
     = help: the following implementations were found:
     = help: the following implementations were found:
               <TryReserveError as From<TryReserveErrorKind>>
     = note: required because of the requirements on the impl of `FromResidual<Result<Infallible, core::alloc::LayoutError>>` for `Result<*mut ArcInner<[T]>, TryReserveError>`
note: required by `from_residual`
     |
     |
339  |     fn from_residual(residual: R) -> Self;

Some errors have detailed explanations: E0277, E0308, E0433.
For more information about an error, try `rustc --explain E0277`.
error: could not compile `alloc` due to 7 previous errors

bors · 2021-10-20T01:34:33Z

☔ The latest upstream changes (presumably #90067) made this pull request unmergeable. Please resolve the merge conflicts.

JohnCSimon · 2021-12-05T02:17:47Z

@Ericson2314
Ping from triage: I'm closing this one due to inactivity, please feel to reopen when you are ready to continue with this.

@rustbot label: +S-inactive

Xuanwo · 2021-12-05T17:57:34Z

As discussed in #86942 (comment), I'm interested in taking over this PR. How could I continue this work? Maybe I need to fork from @Rust-for-Linux and send a new PR?

the8472 · 2021-12-05T18:12:46Z

You can fetch the latest commit from rust-lang (PR commits are available as remote refs) and create a branch from it, rebase it against master and open a new PR.

rust-highfive assigned Mark-Simulacrum Jul 7, 2021

rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Jul 7, 2021

Ericson2314 commented Jul 7, 2021

View reviewed changes

library/alloc/src/slice.rs Outdated Show resolved Hide resolved

Ericson2314 commented Jul 7, 2021

View reviewed changes