---

yaml
---
r: 219050
b: refs/heads/snap-stage3
c: 09c6203
h: refs/heads/master
v: v3

Author: tshepang

[refs]

@@ -1,6 +1,6 @@
 ---
 refs/heads/master: c044791d80ea0dc5c4b57b6030a67b69f8510239
-refs/heads/snap-stage3: dc99fdbd664a936d5f31783774a1362491b31e14
+refs/heads/snap-stage3: 09c6203ad6508dcf3374cddfc2778b861cd9a6be
 refs/heads/try: b53c0f93eedcdedd4fd89bccc5a3a09d1c5cd23e
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596

branches/snap-stage3/src/doc/trpl/traits.md

@@ -215,7 +215,7 @@ it won’t affect you, unless you `use` that trait.
 There’s one more restriction on implementing traits: either the trait, or the
 type you’re writing the `impl` for, must be defined by you. So, we could
 implement the `HasArea` type for `i32`, because `HasArea` is in our code. But
-if we tried to implement `Float`, a trait provided by Rust, for `i32`, we could
+if we tried to implement `ToString`, a trait provided by Rust, for `i32`, we could
 not, because neither the trait nor the type are in our code.
 
 One last thing about traits: generic functions with a trait bound use