@@ -30,8 +30,8 @@ representation of types, but in reality it reflects more of what the user wrote,
3030wrote so as to represent that type.
3131
3232In contrast, ` ty::Ty ` represents the semantics of a type, that is, the * meaning* of what the user
33- wrote. For example, ` rustc_hir::Ty ` would record the fact that a user used the name ` u32 ` twice in their
34- program, but the ` ty::Ty ` would record the fact that both usages refer to the same type.
33+ wrote. For example, ` rustc_hir::Ty ` would record the fact that a user used the name ` u32 ` twice
34+ in their program, but the ` ty::Ty ` would record the fact that both usages refer to the same type.
3535
3636** Example: ` fn foo(x: u32) → u32 { } ` ** In this function we see that ` u32 ` appears twice. We know
3737that that is the same type, i.e. the function takes an argument and returns an argument of the same
@@ -68,9 +68,9 @@ HIR is built, some basic type inference and type checking is done. During the ty
6868figure out what the ` ty::Ty ` of everything is and we also check if the type of something is
6969ambiguous. The ` ty::Ty ` then, is used for type checking while making sure everything has the
7070expected type. The [ ` astconv ` module] [ astconv ] , is where the code responsible for converting a
71- ` rustc_hir::Ty ` into a ` ty::Ty ` is located. This occurs during the type-checking phase, but also in other
72- parts of the compiler that want to ask questions like "what argument types does this function
73- expect"?.
71+ ` rustc_hir::Ty ` into a ` ty::Ty ` is located. This occurs during the type-checking phase,
72+ but also in other parts of the compiler that want to ask questions like "what argument types does
73+ this function expect"?.
7474
7575[ astconv ] : https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/astconv/index.html
7676
@@ -85,11 +85,11 @@ we determine that they semantically are the same type and that’s the `ty::Ty`
8585
8686Consider another example: ` fn foo<T>(x: T) -> u32 ` and suppose that someone invokes ` foo::<u32>(0) ` .
8787This means that ` T ` and ` u32 ` (in this invocation) actually turns out to be the same type, so we
88- would eventually end up with the same ` ty::Ty ` in the end, but we have distinct ` rustc_hir::Ty ` . (This is
89- a bit over-simplified, though, since during type checking, we would check the function generically
90- and would still have a ` T ` distinct from ` u32 ` . Later, when doing code generation, we would always
91- be handling "monomorphized" (fully substituted) versions of each function, and hence we would know
92- what ` T ` represents (and specifically that it is ` u32 ` ).
88+ would eventually end up with the same ` ty::Ty ` in the end, but we have distinct ` rustc_hir::Ty ` .
89+ (This is a bit over-simplified, though, since during type checking, we would check the function
90+ generically and would still have a ` T ` distinct from ` u32 ` . Later, when doing code generation,
91+ we would always be handling "monomorphized" (fully substituted) versions of each function,
92+ and hence we would know what ` T ` represents (and specifically that it is ` u32 ` ).
9393
9494Here is one more example:
9595
@@ -104,10 +104,10 @@ mod b {
104104}
105105```
106106
107- Here the type ` X ` will vary depending on context, clearly. If you look at the ` rustc_hir::Ty ` , you will
108- get back that ` X ` is an alias in both cases (though it will be mapped via name resolution to
109- distinct aliases). But if you look at the ` ty::Ty ` signature, it will be either ` fn(u32) -> u32 ` or
110- ` fn(i32) -> i32 ` (with type aliases fully expanded).
107+ Here the type ` X ` will vary depending on context, clearly. If you look at the ` rustc_hir::Ty ` ,
108+ you will get back that ` X ` is an alias in both cases (though it will be mapped via name resolution
109+ to distinct aliases). But if you look at the ` ty::Ty ` signature, it will be either ` fn(u32) -> u32 `
110+ or ` fn(i32) -> i32 ` (with type aliases fully expanded).
111111
112112## ` ty::Ty ` implementation
113113
@@ -466,9 +466,10 @@ You may have a couple of followup questions…
466466replace a ` SubstRef ` with another list of types.
467467
468468[ Here is an example of actually using ` subst ` in the compiler] [ substex ] . The exact details are not
469- too important, but in this piece of code, we happen to be converting from the ` rustc_hir::Ty ` to a real
470- ` ty::Ty ` . You can see that we first get some substitutions (` substs ` ). Then we call ` type_of ` to
471- get a type and call ` ty.subst(substs) ` to get a new version of ` ty ` with the substitutions made.
469+ too important, but in this piece of code, we happen to be converting from the ` rustc_hir::Ty ` to
470+ a real ` ty::Ty ` . You can see that we first get some substitutions (` substs ` ). Then we call
471+ ` type_of ` to get a type and call ` ty.subst(substs) ` to get a new version of ` ty ` with
472+ the substitutions made.
472473
473474[ substex ] : https://github.com/rust-lang/rust/blob/597f432489f12a3f33419daa039ccef11a12c4fd/src/librustc_typeck/astconv.rs#L942-L953
474475
0 commit comments