Re: [PATCH] x86/Kconfig: make CFI_AUTO_DEFAULT depend on !RUST

[Peter Zijlstra <peterz@infradead.org>]

On Thu, Apr 10, 2025 at 04:54:20PM +0200, Miguel Ojeda wrote:
> On Thu, Apr 10, 2025 at 4:08 PM Peter Zijlstra <peterz@infradead.org> wrote:
> >
> > Maybe I've been living in C/C++ land for too long, but you either expose
> > a full language feature and then everybody can use it, runtime,
> > libraries and user code alike, or you don't.
> 
> I find it unlikely that C++ stdlibs happen to build and work properly
> with compilers they are not tested for. Say, MS' STL with GCC or
> libc++ with MSVC.

Ignoring MSVC, which is a horrible joke of a compiler (or did Sutter
finally cluebat that team into building a sane compiler?), there are
definitely cross compiler STL implementations around.

> At the very least, you need to agree on builtins or `#ifdef` stuff
> manually for magic bits, and you need to avoid to rely on any compiler
> detail (or bug... :) anywhere (say, the non-conforming template
> behavior from old MSVC), and so on. So you need an active effort to
> make it work, I would expect.

Again, with the exception of MSVC, Boost builds on most C++ compilers
and is the staging ground for many new library features.

> And with new complex features like modules, I find it even more
> unlikely the first implementations of a compiler's stdlib would happen
> to work on the first implementation of the feature of another
> compiler...

Sure, shit happens, but... at least they try, it *should* work.

And the old STL (although STL really is far more a library than runtime,
it being fully optional) will most certainly build on a new compiler
from the same family.

And I know Linus hates on C++ something mighty, but in this parallel
universe where he doesn't, I would still recommend the kernel to not use
STL and instead build its own libraries (or borrow some nice pieces here
and there).

> Now, it is true that Rust's `core` uses a lot of internal features,
> precisely because they don't expect to be built by anything else that
> the current (and current - 1) compiler, so they actually take
> advantage of that.

So I don't think this is a good thing. Even builtin stuff should be
more stable than this.

> It would perhaps be nice to split the "really requires magic" in
> `core` from the rest somehow. In this case it wouldn't have helped
> though, since the formatting machinery still uses builtins last time I
> looked.

Right, to the point where we can carry a copy of the non-magic part
locally that matches the minimum version requirement. And no other bits
are to be used by in-tree rust code.

> Relatedly, GCC Rust's goal is to build an old `core` at the moment, so
> that they have a fixed set of things to solve.

Very sensible. The Rust project should have an stable core subset / variant
:-)