---

yaml
---
r: 224506
b: refs/heads/beta
c: dba548d
h: refs/heads/master
v: v3

Author: Gankra

[refs]

@@ -23,7 +23,7 @@ refs/tags/0.9: 36870b185fc5f5486636d4515f0e22677493f225
 refs/tags/0.10: ac33f2b15782272ae348dbd7b14b8257b2148b5a
 refs/tags/0.11.0: e1247cb1d0d681be034adb4b558b5a0c0d5720f9
 refs/tags/0.12.0: f0c419429ef30723ceaf6b42f9b5a2aeb5d2e2d1
-refs/heads/beta: 04578f6611ca5da47b23fa0d10381f7858b3a325
+refs/heads/beta: dba548d3634d1f69b6210b642e700c2c41e69ce9
 refs/tags/1.0.0-alpha: e42bd6d93a1d3433c486200587f8f9e12590a4d7
 refs/heads/tmp: 938f5d7af401e2d8238522fed4a612943b6e77fd
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f

branches/beta/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.