Maybe you understood this as purely a rhetorical question, rather than I'm lazy and didn't take time to go read the source code yet when I wrote it. I apologise.
So, the implementation of Add for String in the kernel when it exists gives a String, it does not give a Result.
What is unclear to me still is the significance of no_global_oom_handling. If this is the intended final state of Rust for Linux, then in fact all these traits just go away, so, you can't concatenate Strings with the + operator, and in fact most ways to do stuff with Strings in Rust go away too†. Which is one way to approach it, it's not as though people were dying to do string manipulation inside the Linux kernel anyway.
† In Rust the String type is a growable heap allocated data structure you can change while str (mostly seen as the reference &str) is just a "slice", a length, plus a memory location, plus a promise that the series of bytes in the slice form valid UTF-8 encoded Unicode, but with no way to grow or change it.
Rust's String type is in the standard library [1], rather than in the language core where things like str live [2]. There's a lot of stuff in the standard library that assumes that it can allocate, and will panic on failure. The solution for now is simply to use Rust's `no_std` support [3] and not import the standard library into kernel code, since it's unsuitable for writing kernel code. In the longer term, Rust is investigating adding fallible variants for all of the standard library traits, so that kernel code could use the standard library with a compiler flag enabled that bans usage of any of the infallible standard library traits. There was a lot of discussion about this a few months ago in https://news.ycombinator.com/item?id=26812047.
Maybe you understood this as purely a rhetorical question, rather than I'm lazy and didn't take time to go read the source code yet when I wrote it. I apologise.
So, the implementation of Add for String in the kernel when it exists gives a String, it does not give a Result.What is unclear to me still is the significance of no_global_oom_handling. If this is the intended final state of Rust for Linux, then in fact all these traits just go away, so, you can't concatenate Strings with the + operator, and in fact most ways to do stuff with Strings in Rust go away too†. Which is one way to approach it, it's not as though people were dying to do string manipulation inside the Linux kernel anyway.
† In Rust the String type is a growable heap allocated data structure you can change while str (mostly seen as the reference &str) is just a "slice", a length, plus a memory location, plus a promise that the series of bytes in the slice form valid UTF-8 encoded Unicode, but with no way to grow or change it.