fix(option1): Add test for prematurely passing exercise
Fixes the bug referenced in #160, but does not address the larger feature work referenced by the issue.
fix(test1): Swap assertion parameter order
`Expected` should come before `actual`, other wise it leads to confusing compiler messages, e.g.
```
note: expected type `()`
found type `{integer}`
```
There may be other tests that need updating, but this is as far as I am through the Rustlings course right now :)
feat(iterators2): adds iterators2 exercise including config
Hi there!
I really enjoyed doing the rustlings exercises so I thought that I would try to add an exercise!
This one just covers a couple of basic iterator operations. Getting people used to the `map` and `collect` functions.
However, it does feel kinda similar to the next exercise. So I may also revisit some of the tests in iterators3 if we think that is necessary.
chore: Clean up some formatting in exercises
I noticed some formatting that isn't consistent with the `rustfmt` style and tried my best to run it on the files in the exercises directory (which does fail for files that can't compile!), which just caught some minor whitespace things here and there.
Note: also can't just apply `rustfmt` blindly because of the blank lines that lead to the hint comments
Fixes the irrefutable let pattern warning in `structs1.rs`
PR https://github.com/rust-lang/rustlings/pull/163 accidentally introduced an error using some versions of the Rust compiler where the compiler would (rightly!) complain about an irrefutable let pattern. I have no idea why this did not occur in all versions of the compiler, but here is a way around it.
fix(installation): Fix rustlings installation check
fixes#147
I did some quick testing with the `-x` check:
```sh
if [ -x "$(notrustlings)" ]
then
echo "notrustlings does not exist"
else
echo "notrustlings appears to exist!"
notrustlings
fi
```
which produced:
```
./test.sh: line 12: notrustlings: command not found
notrustlings appears to exist!
./test.sh: line 17: notrustlings: command not found
```
(consistent with comments in issue)
Using `if ! [ -x "$(command -v <command>)" ]` appears to be the standard way to perform this type of check.
chore: Minor text updates
- Make the default rustlings executable text consistent with the README and install script by adding `--force`.
- Remove a missed highlighting character from Issue #133.
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`?
bors
