Clippy error in test_result.rs

[cs-clarence]

Reopening for https://github.com/esp-rs/rust/issues/231

Min repro: https://github.com/cs-clarence/esp-rs-min-repro

MCU: esp32s3 Rust Version: 1.82 Edition: 2021

Steps to reproduce:

1. Generate a project cargo generate esp-rs/esp-idf-template cargo
2. Create a lib.rs in src folder
3. Restart rust analyzer

found a related PR for this https://github.com/esp-rs/rust/pull/232

cc @MabezDev

[ivmarkov]

@cs-clarence

The TL;DR is that if you wait a couple of weeks or a month (and update to latest Rust nightly and/or esp toolchain), the problem might likely resolve itself because of this and then you won't need the harness = false workaround anymore.

Elaboration: The problem is very deep actually. Here's the context:

• Rust Analyzer - these days - runs with [cfg(test)] enabled by default
• This - in turn - causes cargo itself to try to compile the so called "test harness" lib described here
  • This cargo/rust lib generates on-the-fly (or similar) code for a binary with a regular fn main() STD entrypoint, which main is containing code that (a) references all #[cfg(test)] modules in your app and (b) executes all or one of your #[test] functions
  • Unfortunately - and by design - the code generated by this lib works only on multi-process STD (ESP IDF is not multi-process) and what happens when Rust Analyzer enables the #[cfg(test)] thing is that cargo - behind the curtains - tries to compile the lib
  • This obviously fails, as the lib is trying to spawn processes and stuff, and that can't work

Now, what can we do? Maybe a short-term solution and a log-term solution:

• Short-term - upstream in libc and possibly in Rust STD enough "support" for multi-process execution so that at least the compilation of the test harness code does not fail. "support" is in quotes, because there is just no way for the resulting binary to do anything useful, as ESP-IDF is not multi-process. But we can at least "fake" the multi-process aspect of STD (as we already do a bit now) enough for the stuff to at least compile and not bother you. This is exactly what the change by @SergioGasquez from above does for which I suggested you wait a bit
• Long-term - we do need an actual, operational test harness for ESP-IDF. Obviously, this would be a HIL-based one in that you need to flash it to the chip so that it executes. There is this which probably even runs (?) on esp-baremetal, but I don't think anybody had tried it yet with the ESP IDF. Also do note that with that guy, switching back to harness = false is inescapable in that you still have to set it (and also set #[embedded_test::tests] for the embedded-test harness to actually kick in). There was some talk that the harness parameter should be target-specific actually, and there are some open bugs in cargo about that, but nobody is pushing on that front.

[cs-clarence]

@ivmarkov thanks for the in-depth reply to this. I don't really get the harness = false workaround. The minimal reproduction is generated from the template esp-rs/esp-idf-template which already has the harness = false set. When the file is only main.rs the program compiles fine, however once I create the lib.rs it triggers the clippy error. Initially I thought that it might be my installation is broken but after seeing the github action here https://github.com/cs-clarence/esp-rs-min-repro/actions/runs/11762240597/job/32764909696 I'm convinced that the issue is not just because of my development setup.

[ivmarkov]

@ivmarkov thanks for the in-depth reply to this. I don't really get the harness = false workaround. The minimal reproduction is generated from the template esp-rs/esp-idf-template which already has the harness = false set. When the file is only main.rs the program compiles fine, however once I create the lib.rs it triggers the clippy error.

esp-idf-template's harness = false only applies the workaround for binary crates, as that's what esp-idf-template generates. The moment you put a lib.rs in your crate, you are in fact creating a mixed crate that is simultaneously a binary one and a library one. So you need to then also add to Cargo.toml:

[lib]
harness = false

[cs-clarence]

@ivmarkov thanks for the in-depth reply to this. I don't really get the harness = false workaround. The minimal reproduction is generated from the template esp-rs/esp-idf-template which already has the harness = false set. When the file is only main.rs the program compiles fine, however once I create the lib.rs it triggers the clippy error.

esp-idf-template's harness = false only applies the workaround for binary crates, as that's what esp-idf-template generates. The moment you put a lib.rs in your crate, you are in fact creating a mixed crate that is simultaneously a binary one and a library one. So you need to then also add to Cargo.toml:

[lib]
harness = false

Ah I see. I didn't know this one. That fixed it.

Thanks. I'll be closing this now