---

yaml
---
r: 129445
b: refs/heads/snap-stage3
c: 0cffa32
h: refs/heads/master
i:
  129443: 71748c3
v: v3

Author: emberian

[refs]

@@ -1,7 +1,7 @@
 ---
 refs/heads/master: 566b470e138e929e8a93d613372db1ba177c494f
 refs/heads/snap-stage1: e33de59e47c5076a89eadeb38f4934f58a3618a6
-refs/heads/snap-stage3: c630d961667e9a1f35ea2c55c2558d8c9705ca44
+refs/heads/snap-stage3: 0cffa32c21b08cec443dd2d0388e39cf381b6bfc
 refs/heads/try: 80b45ddbd351f0a4a939c3a3c4e20b4defec4b35
 refs/tags/release-0.1: 1f5c5126e96c79d22cb7862f75304136e204f105
 refs/heads/ndm: f3868061cd7988080c30d6d5bf352a5a5fe2460b

branches/snap-stage3/src/librustc/middle/ty.rs

@@ -790,6 +790,13 @@ pub enum sty {
     ty_int(ast::IntTy),
     ty_uint(ast::UintTy),
     ty_float(ast::FloatTy),
+    /// Substs here, possibly against intuition, *may* contain `ty_param`s.
+    /// That is, even after substitution it is possible that there are type
+    /// variables. This happens when the `ty_enum` corresponds to an enum
+    /// definition and not a concerete use of it. To get the correct `ty_enum`
+    /// from the tcx, use the `NodeId` from the `ast::Ty` and look it up in
+    /// the `ast_ty_to_ty_cache`. This is probably true for `ty_struct` as
+    /// well.`
     ty_enum(DefId, Substs),
     ty_box(t),
     ty_uniq(t),