Skip to content

Commit ba48252

Browse files
JohnTitormark-i-m
authored andcommitted
Fix line length
1 parent 2ef6c92 commit ba48252

File tree

1 file changed

+18
-17
lines changed

1 file changed

+18
-17
lines changed

src/ty.md

Lines changed: 18 additions & 17 deletions
Original file line numberDiff line numberDiff line change
@@ -30,8 +30,8 @@ representation of types, but in reality it reflects more of what the user wrote,
3030
wrote so as to represent that type.
3131

3232
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.
3535

3636
**Example: `fn foo(x: u32) → u32 { }`** In this function we see that `u32` appears twice. We know
3737
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
6868
figure out what the `ty::Ty` of everything is and we also check if the type of something is
6969
ambiguous. The `ty::Ty` then, is used for type checking while making sure everything has the
7070
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"?.
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

8686
Consider another example: `fn foo<T>(x: T) -> u32` and suppose that someone invokes `foo::<u32>(0)`.
8787
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`).
9393

9494
Here 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…
466466
replace 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

Comments
 (0)