---

yaml
---
r: 229018
b: refs/heads/try
c: dba548d
h: refs/heads/master
v: v3

Author: Gankra

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: aca2057ed5fb7af3f8905b2bc01f72fa001c35c8
 refs/heads/snap-stage3: 1af31d4974e33027a68126fa5a5a3c2c6491824f
-refs/heads/try: 04578f6611ca5da47b23fa0d10381f7858b3a325
+refs/heads/try: dba548d3634d1f69b6210b642e700c2c41e69ce9
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/tags/release-0.2: c870d2dffb391e14efb05aa27898f1f6333a9596
 refs/tags/release-0.3: b5f0d0f648d9a6153664837026ba1be43d3e2503

branches/try/src/doc/tarpl/repr-rust.md

@@ -109,7 +109,7 @@ struct FooRepr {
 
 And indeed this is approximately how it would be laid out in general
 (modulo the size and position of `tag`). However there are several cases where
-such a representation is ineffiecient. The classic case of this is Rust's
+such a representation is inefficient. The classic case of this is Rust's
 "null pointer optimization". Given a pointer that is known to not be null
 (e.g. `&u32`), an enum can *store* a discriminant bit *inside* the pointer
 by using null as a special value. The net result is that
@@ -121,4 +121,4 @@ nested enums pooling their tags into a single descriminant, as they are by
 definition known to have a limited range of valid values. In principle enums can
 use fairly elaborate algorithms to cache bits throughout nested types with
 special constrained representations. As such it is *especially* desirable that
-we leave enum layout unspecified today.
+we leave enum layout unspecified today.