RUST_RECURSION_COUNT: error: infinite recursion detected

[haraldh]

Describe the bug
rustup keeps track of recursion via the RUST_RECURSION_COUNT
environment variable.

Since cargo make uses up one increment, a chain of

• cargo clippy
  -> cargo check
  -> rustc -vV
  -> ...

Uses up to rustup::env_var::RUST_RECURSION_COUNT_MAX and we get the
error message:

[cargo-make][2] INFO - Running Task: clippy
[cargo-make][2] INFO - Execute Command: "cargo" "clippy"
error: process didn't exit successfully: `rustc -vV` (exit code: 1)
--- stderr
error: infinite recursion detected

To Reproduce

• a clean repo (no Cargo.lock)
• cargo clippy enabled on stable
• cargo make ci

Fix
Clear or set RUST_RECURSION_COUNT = 0

[sagiegurari]

cargo make runs commands which are sub processes so they can't update each other or share env vars. feels like a clippy issue.

[haraldh]

Oh, you can unset the variable inside cargo-make before calling more cargo stuff.

[haraldh]

And it is not a clippy issue...
This patch fixes the issue for us:
enarx/enarx@185d4da

[env]
RUST_RECURSION_COUNT = 0

[sagiegurari]

ya, I'm sure it fixes things, but doesn't explain the root cause.
what I'm trying to understand how can unrelated processes share an env which is not possible.
fact you can workaround it via setting that env, might just hide something else.

i always use all features, including clippy in both crate and workspace projects, and i rum the ci flow before push and never got that.

so the only difference i see it, is different rust/clippy versions.

[haraldh]

We use the current versions for stable and nightly. And in only occurs on fresh projects, without target and Cargo.lock.

[haraldh]

ya, I'm sure it fixes things, but doesn't explain the root cause.

The root cause is, that cargo make is the first RUST_RECURSION_COUNT++, and that you pass the RUST_RECURSION_COUNT env to the childs, so any job from ~/.cargo/bin/* hard linked to rustup (like cargo and rustc) starts with RUST_RECURSION_COUNT=1 instead of 0.

Running cargo clippy on a complete empty crate seems to use all allowed rustup::env_var::RUST_RECURSION_COUNT_MAX
https://github.com/rust-lang/rustup/blob/bb0fd7b5f56bf5afd030cc2a251bea0c973313ad/src/bin/rustup-init.rs#L96
and with cargo make in front, it exceeds that.

[sagiegurari]

so it is a clippy issue if it maxes it out.
I'm ok with pushing that env var into cargo make internal makefile, just wanted to understand more.
i sometimes add workarounds for other rust/tools in the makefile, so thats another one to workaround clippy bug. so I'll add it specifically to the clippy task, and not in global env. makes sense?

[haraldh]

Well, it's a rustup issue. If you call other rustup components they might call themselves rustup components. So, it's not clippy alone.

Will affect also:

• clippy
• llvm-tools-preview
• miri
• rls
• rust-analysis
• rust-docs
• rustc
• rustfmt

[sagiegurari]

ya, so i did unset on global level. i never ran into this, but cant harm anything i guess...

[sagiegurari]

this is now released in the new cargo-make version 0.32.2

[haraldh]

Thanks!