@@ -30,8 +30,8 @@ representation of types, but in reality it reflects more of what the user wrote,
30
30
wrote so as to represent that type.
31
31
32
32
In 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.
35
35
36
36
** Example: ` fn foo(x: u32) → u32 { } ` ** In this function we see that ` u32 ` appears twice. We know
37
37
that 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
68
68
figure out what the ` ty::Ty ` of everything is and we also check if the type of something is
69
69
ambiguous. The ` ty::Ty ` then, is used for type checking while making sure everything has the
70
70
expected 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"?.
74
74
75
75
[ astconv ] : https://doc.rust-lang.org/nightly/nightly-rustc/rustc_typeck/astconv/index.html
76
76
@@ -85,11 +85,11 @@ we determine that they semantically are the same type and that’s the `ty::Ty`
85
85
86
86
Consider another example: ` fn foo<T>(x: T) -> u32 ` and suppose that someone invokes ` foo::<u32>(0) ` .
87
87
This 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 ` ).
93
93
94
94
Here is one more example:
95
95
@@ -104,10 +104,10 @@ mod b {
104
104
}
105
105
```
106
106
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).
111
111
112
112
## ` ty::Ty ` implementation
113
113
@@ -466,9 +466,10 @@ You may have a couple of followup questions…
466
466
replace a ` SubstRef ` with another list of types.
467
467
468
468
[ 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.
472
473
473
474
[ substex ] : https://github.com/rust-lang/rust/blob/597f432489f12a3f33419daa039ccef11a12c4fd/src/librustc_typeck/astconv.rs#L942-L953
474
475
0 commit comments