fix(run): makes `run` never prompt
`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
feat(cli): check for rustc before doing anything
Addresses #190. From the backtraces shown there, it seems like we're not able to launch `rustc` (which is odd, given that they probably compiled and installed `rustlings` 🤷♀️)
Refactor hints
Breaking change. This removes hints from the end of files, and puts them into `info.toml`. You can now access hints using:
```
rustlings hint <exerciseName>
```
ALSO this changes the exercise system to index by name for `run` and `hint`, so:
```
rustlings run exercises/if/if1.rs
```
becomes
```
rustlings run if1
```
Changes the execution mode for `watch`, asking for user input
We've [observed](https://hackmd.io/-cK6aPhnTwiCiI7u6k0xug?both) that learners can get confused when they do get everything right, but they _still_ get errors... which come from the next exercise, no the one they just edited.
This PR changes it so they have to confirm they want to move forward by removing the `I AM NOT DONE` comment.
* [ ] The particular string is of course subject to bikeshed.
### Alternatives/doubts
* The coolest solution I could imagine would involve a proc-macro attribute `#![ready(false)]` that they could edit once they're done, but it's a bit complicated to set up.
* For now I've put `I AM NOT DONE` everywhere, I think it's what make more sense.
feat: Add enums exercises
Creates an exhaustive list of enum exercises. This goes through the basics of different ways to derive enums with mixed data type variants, as well as the use of the all important `match` operator.
watch: clears terminal before entering loop
Fixes#146
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.
Note that the escape character is chosen for compatibility reasons, because different shells/terminals can change which commands they accept or have installed, betting on what other commands are in use to collect data seems risky, and just expecting them to implement ANSI escape code sequences is more reliable. This seems especially true since Windows is seeking more UNIX compatibility in its terminals going forward, even though it doesn't implement the POSIX standard per se.
chore: Clarify comment in exercises/test1.rs
closes#194
The author of issue #194 suggests that the wording of the comment is at
least ambiguous about the desired results. I believe this change more
clearly describes the expectation of the exercise.
Add windows install script
Adds a powershell install script for windows users that are at least
running powershell 5. It is almost a direct port of install.sh.
This would be used to automatically download the script much like
curl | bash, but with:
`Invoke-WebRequest https://urltoscript.com | Select-Object
-ExpandProperty Content | Out-File $env:TMP/install_rustlings.ps1;
Unblock-File $env:TMP/install_rustlings.ps1; Invoke-Expression
$env:TMP/install_rustlings.ps1`
fix(errorsn.rs) Update the deprecated syntax by adding dyn to trait o…
fix(errorsn.rs) Update the deprecated syntax by adding dyn to trait objects.
closes#211
Related issue: https://github.com/rust-lang/rustlings/issues/211
fix(primitive_types4): Fail on a slice covering the wrong area
I noticed this issue and it seems like a similar one was raised/fixed in #160 this way. This is my first contribution to this repo (or any Rust project) so let me know if I messed up or need to fix anything!
---
This commit converts primitive_types4 to a test and asserts that the
slice given is equal to the expected slice.
The intent of the primitive_types4 exercise appears to be to ensure the
user understands inclusive and exclusive bounds as well as slice syntax.
`rustlings` commands using `compile` do not verify that a specific
println is reached and, in the case of `watch` and `verify` (but not
`run`), they do not output the `println`s at all.
This fix is semantically similar to #198. It does not take a stance on
the correct way to handle this for all exercises; see #127. There are
likely other exercises whose intent are masked by this issue.
Suggest rustup update in readme
I'm pretty new to Rust. I tried installing rustlings for the first time and got this error:
```
$> cargo install --force --path .
error: `/Users/ajax/projects/rust/rustlings` is not a crate root; specify a crate to install from crates.io, or use --path or --git to specify an alternate source
Caused by:
failed to parse manifest at `/Users/ajax/projects/rust/rustlings/Cargo.toml`
Caused by:
editions are unstable
Caused by:
feature `edition` is required
this Cargo does not support nightly features, but if you
switch to nightly channel you can add
`cargo-features = ["edition"]` to enable this feature
```
I'm not sure if the answer was to run `rustup update` but I noticed that I was running Rust 1.29.0, so updated to 1.36.0 and got it working. If there's a way to specify a minimum required version, pls let me know.
Lastly, the whitespace changes were automatic from my editor. What's the convention here for making such updates? Thanks!
Fix iterators2
A couple of small changes to the `iterators2` exercise. @Jesse-Cameron, it looks like you contributed this exercise, so I wanted to check and see if these changes are in line with your intentions. Happy to adjust if they're not :)
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
