---

yaml
---
r: 236089
b: refs/heads/stable
c: dba548d
h: refs/heads/master
i:
  236087: ab71ad9
v: v3

Author: Gankra

[refs]

@@ -29,7 +29,7 @@ refs/heads/tmp: afae2ff723393b3ab4ccffef6ac7c6d1809e2da0
 refs/tags/1.0.0-alpha.2: 4c705f6bc559886632d3871b04f58aab093bfa2f
 refs/tags/homu-tmp: f859507de8c410b648d934d8f5ec1c52daac971d
 refs/tags/1.0.0-beta: 8cbb92b53468ee2b0c2d3eeb8567005953d40828
-refs/heads/stable: 04578f6611ca5da47b23fa0d10381f7858b3a325
+refs/heads/stable: dba548d3634d1f69b6210b642e700c2c41e69ce9
 refs/tags/1.0.0: 55bd4f8ff2b323f317ae89e254ce87162d52a375
 refs/tags/1.1.0: bc3c16f09287e5545c1d3f76b7abd54f2eca868b
 refs/tags/1.2.0: f557861f822c34f07270347b94b5280de20a597e

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