Add errors to exercises that compile without user changes
Hi !
I played a bit with rustlings, and I felt that some exercises were incorrect because they passed the tests without me needing to edit the files!
This gave me the feeling that the exercise was skiped! Especially when I use `rustlings watch`, it is easy to miss an exercise because the compilation error that is displayed is the one of the next exercise ...
It is easy to identify "broken" exercises with:
```bash
% find exercises -name "*.rs" | xargs -n 1 rustlings run
...
✅ Successfully ran exercises/move_semantics/move_semantics4.rs
✅ Successfully tested exercises/test2.rs
```
My suggestion is to make sure that these files trigger a compilation error by adding a simple syntax error (e.g. with `???` in the code that must change) so that our Rustacean can then play with it!
Canonicalize paths to fix path matching
This PR should fix#126. The main solution to the issue was using `canonicalize()` on the paths we create for the exercises from `info.toml` and any user-specified paths, so that path `ends_with` matching will work correctly.
As adding calls to the canonicalize function everywhere requires unwrapping, I also decided to extract a struct representing an exercise and use serde to deserialize the paths from the `info.toml` file up front. I also tried to move the path handling out into the `exercise.rs` file and down into `main.rs` so that it doesn't create as much clutter. There was already a lot of unwrapping and path handling in the other files and I felt like it was getting a bit too repetitive.
If the approach is going too far (too many changes etc.) I'm happy to try to produce a smaller PR that fixes the bug without any refactoring.
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.
Stop run from panicking when compile fails
Currently if you use the `rustlings run` command and your program fails to compile, rustlings will panic while trying to exit.
First I've added a couple of integration tests to cover this case, which also meant moving a few tests so that the new fixtures didn't cause `verify_all_success` to fail.
Then I noticed that the existing integration tests that test for failure pass even when rustlings panics, preventing the new tests from failing. I've updated the integration tests to distinguish between when rustlings has failed in the way that we want (exit code 1) rather than a panic (exit code 101).
Finally I fixed the actual panic, which was just caused by unwrapping when rustlings should probably be exiting cleanly.
fix watch command path execution
@hades32 @guttume could you test whether this works on windows by checking out the branch locally and running `cargo run watch`?
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.
Eddy Petrisor
