> Le 18 juil. 2025 à 19:04, Ezekiel Newren <ezekielnewren@xxxxxxxxx> a écrit :
>
> On Thu, Jul 17, 2025 at 3:23 PM brian m. carlson
> <sandals@xxxxxxxxxxxxxxxxxxxx> wrote:
>>
>>> 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.
>
>>> +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’.
Are functions that exist for C FFI callers supposed to be marked unsafe, and if so: does that prevent the dead code analyzer from removing them w/o the allow flag?
Or, alternatively, can we #[] annotate them as allowed? It might be noisy, but it also lets the checkers flag actually dead 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’.
Similarly, I would think this is a problem with the IDE rather than something we want to end up with in the implementation.
I wonder if one of the cargo fix type things can remove them for you, too, so that it’s easier to just drop this allow.
