Re: [PATCH 7/7] github_workflows: install rust

From: Ezekiel Newren <ezekielnewren@gmail.com>
Date: Jul 18, 2025, 23:01 UTC
Message-ID: <CAH=ZcbAeMv7oO-X_o_WOvgS6_igO3XAUjmgLoEfDN0CqqTMH_g@mail.gmail.com>
In-Reply-To: <aHlp1joMwexLZAAb@fruit.crustytoothpaste.net>

On Thu, Jul 17, 2025 at 3:23 PM brian m. carlson <sandals@crustytoothpaste.net> wrote:

Show 23 quoted lines

>
> On 2025-07-17 at 20:32:24, Ezekiel Newren via GitGitGadget wrote:
> > diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml
> > index 7dbf9f7f123c..8aac18a6ba45 100644
> > --- a/.github/workflows/main.yml
> > +++ b/.github/workflows/main.yml
> > @@ -4,6 +4,7 @@ on: [push, pull_request]
> >
> >  env:
> >    DEVELOPER: 1
> > +  RUST_VERSION: 1.87.0
>
> Our discussed plan is to support the version in Debian stable, plus a
> year.  So we'd be supporting 1.63.0 for a year after trixie's release.
>
> The reason for that is that people build backports and security updates
> for Git for stable releases of distros and they will use the distro
> toolchain for doing so.  Forcing distros to constantly build with the
> latest toolchain is pretty hostile, especially since the lifespan of
> Rust release is six weeks.
>
> If the Rust project provides LTS releases in the future, then we can
> consider adopting those.

The RUST_VERSION variable in .github/workflows/main.yaml had to have a specific version. 1.87.0 was selected since that's what I was using locally. Elijah made me aware that an older version of rust might be desired, but didn't know which one. I'll switch to 1.63.0 or whatever the community decides.

Show 10 quoted lines

> > +if [ "$rust_target" = "release" ]; then
> > +  rust_args="--release"
> > +  export RUSTFLAGS='-Aunused_imports -Adead_code'
> > +elif [ "$rust_target" = "debug" ]; then
> > +  rust_args=""
> > +  export RUSTFLAGS='-Aunused_imports -Adead_code -C debuginfo=2 -C opt-level=1 -C force-frame-pointers=yes'
>
> Can you say a little about why these options are needed and the defaults
> are inadequate?  For instance, I build with the default options both in
> my personal projects and at work and don't see a problem.

What I found is that if I have a Rust function

#[no_mangle] pub fn call_from_c(arg: u64) {}

which is only meant to be called from C and isn’t called from elsewhere in Rust, then cargo will misidentify this function as dead code. This was the reason for adding ‘-Adead_code’.

The reason for adding ‘-Aunused_imports’ is somewhat IDE related; if I paste code somewhere, RustRover will sometimes automatically add the necessary imports. However, if I delete a chunk of code, it’ll highlight the imports that are no longer used if I scroll to the top of the file, but it won’t automatically remove them. Since they aren’t automatically removed, it’s easier to build with ‘-Aunused_imports’.

The remaining arguments, ‘-C debuginfo=2 -C opt-level=1 -C force-frame-pointers=yes’ is to make /usr/bin/perf output more amenable to analysis.

> I don't know if you plan to do this in a future series, but we'd also
> want cargo's tests to be run as part of CI and we'd want a lint job that
> ran clippy with both 1.63.0 and the latest stable version of Rust to
> make sure things were tidy.

Yeah I'd like that too; we can add that in a future patch series.

> --
> brian m. carlson (they/them)
> Toronto, Ontario, CA