Merge pull request #122 from cassiersg/fix-mod

[rust.git] / README.md

diff --git a/README.md b/README.md
index 2835eafeaaeef8a814a9161e08c9eb35735664a1..2bddeb869da655d48fd4f5e17c77bc8af0b29ede 100644 (file)
--- a/README.md
+++ b/README.md
@@ -5,6 +5,8 @@ A tool for formatting Rust code according to style guidelines.
 
 ## How to use
 
+You'll need a pretty up to date version of the **nightly** version of Rust.
+
 `cargo build` to build.
 
 `cargo test` to run all tests.
@@ -49,7 +51,7 @@ move bounds to where clauses, combine multiple impls into a single impl, etc.
 However, we will not change the names of variables or make any changes which
 *could* change the semantics. To be ever so slightly formal, we might imagine
 a compilers high level intermediate representation, we should strive to only
-make changes which do change the HIR, even if they do change the AST.
+make changes which do not change the HIR, even if they do change the AST.
 
 I would like to be able to output refactoring scripts for making deeper changes
 though. (E.g., renaming variables to satisfy our style guidelines).
@@ -87,7 +89,7 @@ when making those changes.
 
 The advantage of the tokens approach are that you can operate on non-parsable
 code. I don't care too much about that, it would be nice, but I think being able
-to sophisticated transformations is more important. In the future I hope to
+to perform sophisticated transformations is more important. In the future I hope to
 (optionally) be able to use type information for informing reformatting too. One
 specific case of unparsable code is macros. Using tokens is certainly easier
 here, but I believe it is perfectly solvable with the AST approach. At the limit,