You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the current plan to run clippy in our analyzer, it would be benefitial to make sure stubs don't trigger clippy warnings.
Currently, an annoyance that impacts many exercises is clippy::new_without_default:
you should consider adding a Default implementation
This lint is definitely good in general settings, but not for us. We don't want to force students to write constructors in terms of the Default trait. They may not even be at a stage of their learning where they are comfortable with traits. And an exercise is not a library to be published where it's important to have the standard traits implemented.
We might consider suppressing this lint (and possibly others) via the recently stabilized lint configuration through cargo. This will keep the code of the student's solution clean and provide a good experience, be that locally or online.
The text was updated successfully, but these errors were encountered:
Implementation idea: Add a new test in rust-tooling/ci-tests. Run clippy over each exercise in parallel by spawning a child process for each. Create a temporary directory for each exercise and point cargo to that as the target directory, to avoid modifying any files in the repo. Don't let child processes inherit stdout (might get messed up due to parallelism), instead collect outputs and collect dem into a nicely formatted logfile (e.g. in the repo root, added to gitignore).
senekor
changed the title
Tets in CI that stubs don't generate clippy warnings
Test in CI that stubs don't generate clippy warnings
Dec 16, 2023
With the current plan to run clippy in our analyzer, it would be benefitial to make sure stubs don't trigger clippy warnings.
Currently, an annoyance that impacts many exercises is
clippy::new_without_default
:This lint is definitely good in general settings, but not for us. We don't want to force students to write constructors in terms of the Default trait. They may not even be at a stage of their learning where they are comfortable with traits. And an exercise is not a library to be published where it's important to have the standard traits implemented.
We might consider suppressing this lint (and possibly others) via the recently stabilized lint configuration through cargo. This will keep the code of the student's solution clean and provide a good experience, be that locally or online.
The text was updated successfully, but these errors were encountered: