Re: [DISCUSS] Introducing Rust into the Git project

From: Antoni Boucher <bouanto@zoho.com>
Date: Jan 12, 2024, 14:46 UTC
Message-ID: <b6fc8dd7be709b350bd50fa507ae03f4c3c89d8d.camel@zoho.com>
In-Reply-To: <87jzofrlm4.fsf@gentoo.org>

While usable, there are a few things missing in rustc_codegen_gcc:

 * Unwinding doesn't work correctly when compiling Rust code in release
mode.
 * Rustup distribution: might not be mandatory, but I guess it would be
very helpful to have an easy way to install rustc_codegen_gcc and being
able to pin to a specific version.
 * Debug info: again might not be mandatory, but would be helpful.
 * Have not been tested on many platforms: these platforms had a few
tests, so while it's possible to use Rust on them, that doesn't mean
everything works (in particular, I know that changes will be needed to
both the Rust spec file and the standard library — or its tests — for
m68k): SuperH, ARC, m68k [1] and there's currently someone
experimenting on AVR. Related to the platform support, could you please
send me a list of platforms where git is officially supported?
 * Not sure if it would be needed, but the new inline asm syntax is not
supported on architectures not supported by rustc.
 * I also expect bad compilation in some cases.

> Is this simply library support in the libc crate?  That's very easy

to add.

We might also need to update the object crate.

As for the progress, we plan to have most of the patches merged for libgccjit 14, but one important one will be missing because it's not ready (the one for try/catch that is necessary to support Rust panics). I expect there will be much less patches for libgccjit 15: probably try/catch and bug fixing for the most part. We also plan to have rustup distribution in the coming months, so that's something that will help for adoption. Along with rustup distribution, we plan on making architectures currently not supported by rustc usable more easily in the coming months.

Recently, I built and ran the tests of a dozen of the most popular crates and all of their tests passed [2]. And rustc_codegen_gcc was already able to build the Rust compiler in March 2022 and while not completely working, the resulting compiler could compile a "Hello, world!" [3].

[1] https://github.com/rust-lang/rustc_codegen_gcc/wiki [2] https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-26#state_of_compiling_popular_crates [3] https://blog.antoyo.xyz/rustc_codegen_gcc-progress-report-10

On Fri, 2024-01-12 at 08:24 +0000, Sam James wrote:

Show 78 quoted lines

> 
> "brian m. carlson" <sandals@crustytoothpaste.net> writes:
> 
> > [[PGP Signed Part:Undecided]]
> > On 2024-01-11 at 11:45:07, Sam James wrote:
> > > Something I'm a bit concerned about is that right now, neither
> > > rustc_codegen_gcc nor gccrs are ready for use here.
> > > 
> > > We've had trouble getting things wired up for rustc_codegen_gcc
> > > - which is not to speak against their wonderful efforts - because
> > > the Rust community hasn't yet figured out how to handle things
> > > which
> > > pure rustc supports yet. See
> > > e.g. https://github.com/rust-lang/libc/pull/3032.
> > 
> > Is this simply library support in the libc crate?  That's very easy
> > to add.
> 
> [CC'd the rustc_codegen_gcc maintainer as well as some folks who have
> tried using rustc_codegen_gcc for their distributions.]
> 
> Evidently not on the last point? ;)
> 
> Even just patching it in downstream isn't easy because you then have
> to
> do it for many many packages. But after that PR stalling because of
> the
> policy issue, there wasn't really anywhere to go, because of the
> chicken-and-egg situation.
> 
> Let alone then, once the libc crate has it, going around and wiring
> up
> in other crates.
> 
> The discussion on the PR seems clear that the intention is to not add
> it until some policy is revised/formulated? I also don't want to have
> to have that debate with every crate just because rustc doesn't
> support
> it.
> 
> > 
> > > I think care should be taken in citing rustc_codegen_gcc and
> > > gccrs
> > > as options for alternative platforms for now. They will hopefully
> > > be great options in the future, but they aren't today, and they
> > > probably
> > > won't be in the next 6 months at the least.
> > 
> > What specifically is missing for rust_codegen_gcc?  I know gccrs is
> > not
> > ready at the moment, but I was under the impression that
> > rust_codegen_gcc was at least usable.  I'm aware it requires some
> > patches to GCC, but distros should be able to carry those.
> > 
> > If rust_codegen_gcc isn't viable, then I agree we should avoid
> > making
> > Rust mandatory, but I'd like to learn more.
> 
> It's in a general state of instability. There's still *very* active
> work
> ongoing in libgccjit (by the rust_codegen_gcc maintainer).
> 
> I'd say "you need to patch your GCC" is probably not a good state of
> affairs for using something critical like git anyway, but even then,
> I'm not aware of anyone having used it to build real-world common
> applications using Rust for a non-rustc-supported platform, at least
> not then using those builds day-to-day.
> 
> So, even if we were willing to chase the active flurry of libgccjit
> patches (which is wonderful to see!), it's a significant moving
> target. In Gentoo, we're probably better-placed than most people
> to be able to do that, but it's still a lot of work and it doesn't
> sound very robust for us to be doing for core infrastructure.
> 
> We have a lot of packages in Gentoo - partly actually stuff in the
> Python ecosystem - where we're very excited to be able to use
> rust_codegen_gcc (or gccrs, whichever comes first inreadiness, surely
> rust_codegen_gcc) for alt platforms, but it's just not there yet.