Additionally to running clippy, also compile the exercise file so that
`rustling run clippy1` works after a successful completion of the
exercise.
closes#291
Signed-off-by: Rohan Jain <crodjer@gmail.com>
When running "compile"-mode exercises in interactive `verify` mode,
we print their output when we prompt the learner if they want to
continue. This improves the "experimentation" experience, since
trying different things does produce a visible change.
The completion message is shown only once all exercises succeed and are
not annotated with "I AM NOT DONE." The watch command will also exit
closes#251
`watch` and `verify` do prompt the user to actively move to the
next exercise. This change fixes `run` to never prompt. Previously
it was inconsistent between "test" and "compile" exercises.
BREAKING CHANGE: we again change the behavior of the `run` command
Hints are now accessible using the CLI subcommand `rustlings hint
<exercise name`.
BREAKING CHANGE: This fundamentally changes the way people interact with exercises.
BREAKING CHANGE: This changes the way you use `rustlings run` by now
requiring an abridged form of the previous filename, e.g:
`rustlings run exercises/if/if1.rs` becomes
`rustlings run if1`
If someone is sliding in and out of "watch" mode, it can make it hard
to tell which error messages are still relevant. This patch resolves
that by clearing the terminal entirely before entering watch's loop.
Fix intermittent test failure caused by race condition
First public pull request 😬
There's an intermittent integration test failure when you use multiple test threads (at least for me on a mac). I narrowed it down to two tests each spawning a process using `Command` which then try to compile the same file at the same time. If the timing doesn't work out, they both try to compile, and then one process runs `clean` before the other can run the executable - causing a panic.
You can prevent it from happening by running with a single thread (`cargo test -- --test-threads=1`), because the `Command` blocks. That's not a particularly good solution though because it's not something you can configure in `Cargo.toml`.
I considered making the affected tests just run serially, but it occurred to me that this could also happen if someone accidentally runs rustlings in watch mode in two terminals without realising it. I wound't consider this that unlikely given it's a tool for learning.
I fixed it by ensuring that the executables made from separate processes don't conflict by appending a process id to the output executable name. I also extracted the commands into a single file next to `clean` so that we don't have to repeat the generated file name everywhere and risk missing something.
Before, rustlings would panic if it wasn't in the right directory. It
took me a minute to figure out why, and this wasn't my first intro to
Rust. It would probably help new users if they saw a helpful message
instead of a stack trace.
