Ci: test crates with the intended targets #669
Conversation
| # Check all RISC-V targets: | ||
| - name: check (esp32c3) | ||
| run: cd esp-hal-smartled/ && cargo +nightly check --features=esp32c3 | ||
| run: cd esp-hal-smartled/ && cargo +nightly check --features=esp32c3 --target=riscv32imc-unknown-none-elf |
There was a problem hiding this comment.
Why does the target matter here? cargo check does not perform code generation, it should not make any difference should it?
| with: | ||
| toolchain: stable | ||
| components: clippy | ||
| toolchain: nightly |
There was a problem hiding this comment.
We were specifically running clippy from the stable release channel so that our lints don't just start failing overnight for no reason. Lints in the nightly version of clippy are also not guaranteed to be stabilized, so I don't see much point adhering to those rules.
There was a problem hiding this comment.
I don't think the crates will pass check with stable. Previously, clippy ran with the host machine as target, so std was available, but now (with cd-ing into the folder instead of --manifest-path cargo will pick up the .cargo/config.toml, set the correct target and there stable will fail as build-std is not stable.
There was a problem hiding this comment.
I guess we could run clippy with the +esp toolchain so that it can pick up the unstable stuff while only checking the stable lints?
bugadani
force-pushed
the
ci
branch
2 times, most recently
from
591b827 to
5212d7d
Compare
2 participants
Thank you!
Thank you for your contribution.
Please make sure that your submission includes the following:
Must
errorsorwarnings.cargo fmtwas run.CHANGELOG.mdin the proper section.Nice to have
This PR is taken from #666 and changes CI to check crates with the intended target. This is not extremely important but prevents weird cases where Xtensa/RISC-V asm is checked as x86 and produces warnings. This PR also ensures that the correct rustflags are set where necessary (i.e. checking S2 vs atomics).