Auto merge of #634 - Areredify:book_typename_fix, r=jackh726

rewrite parts concerning typename, fix links

fixes #631

Author: bors

book/src/types/rust_types.md

@@ -39,10 +39,10 @@ describes why each variant exists.
 
 ### Application types
 
-The `Apply` variant contains an `ApplicationTy`. These are kind of the
-"normal Rust types", like `Vec<u32>` or `f32`. They consist of a "type
-name" (in our examples, `Vec` and `f32` respecively) and zero or more
-generic arguments (respectively, `[u32]` and `[]`).
+Most of "normal rust types" like `Vec<u32>` or `(f32, Vec<isize>)` are represented with 
+`TyKind` variants containing some type-specific info ("type name") and a substitution
+that is "applied" to that type. In this case, type names are `Vec` and "tuple of arity 2",
+and substitutions are `[u32]` and `[f32, Vec<isize>]`.
 
 They are equal to other types (modulo aliases, see below) iff they
 have the same "type name" and the generic arguments are
@@ -61,17 +61,13 @@ placeholder. Similarly, in that same function, the associated type
 Like application types, placeholder *types* are only known to be
 equal.
 
-However, we choose not to represent placeholder types as type names
-because they need to be created during type unification and other
-operations, and hence that would require treating `TypeName` less opaquely.
-
-Moreover, when proving negative goals, e.g., `not { Implemented(T:
+When proving negative goals, e.g., `not { Implemented(T:
 Trait) }`, placeholders are treated quite differently from application
 types, since they do not (in fact) represent a known type. When
-solving negative goals, placeholderes are replaced with inference
+solving negative goals, placeholders are replaced with inference
 variables -- the idea is that this goal is only true if there is *no
 type* `T` that implements `Trait`. Therefore, if we can find no
-answeres for `exists<T> { Implemented(T: Trait) }`, then we know that
+answers for `exists<T> { Implemented(T: Trait) }`, then we know that
 the negation is true. (Note that this means that e.g. `forall<X> { X =
 i32 }` is false but so is `forall<X> { not { X = i32 } }`.)
 
@@ -110,16 +106,16 @@ that is outside the scope of the chalk-ir crate.
 
 ### Function pointer types
 
-The `Fn` variant wraps a `FnTy` struct and represents a `fn()` type
+The `Function` variant wraps a `FnPointer` struct and represents a `fn()` type
 (in other words, a function pointer). In some ways, fn types are like
 application types, but with one crucial difference: they also contain
 a `forall` binder that for lifetimes whose value is determined when
 the function is called. Consider e.g. a type like `fn(&u32)` or --
 more explicitly -- `for<'a> fn(&'a u32)`.
 
-Two `Fn` types `A, B` are equal `A = B` if `A <: B` and `B <: A`
+Two `Function` types `A, B` are equal `A = B` if `A <: B` and `B <: A`
 
-Two `Fn` types `A, B` are subtypes `A <: B` if
+Two `Function` types `A, B` are subtypes `A <: B` if
 
 * After instantiating the lifetime parameters on `B` universally...
     * You can instantiate the lifetime parameters on `A` existentially...
@@ -143,7 +139,7 @@ them in the [aliases chapter](./rust_types/alias.md).
 
 ### Bound variables
 
-The `BoundVariable` variant represents some variable that is bound in
+The `BoundVar` variant represents some variable that is bound in
 an outer term. For example, given a term like `forall<X> {
 Implemented(X: Trait) }`, the `X` is bound. Bound variables in chalk
 (like rustc) use de bruijin indices (See below).
@@ -166,44 +162,41 @@ other type without any effect, and so forth.
 
 ## Mapping to rustc types
 
-The rustc [`TyKind`] enum has a lot more variants than chalk. This
+The rustc [`TyKind`] enum is almost equivalent to chalk's. This
 section describes how the rustc types can be mapped to chalk
 types. The intention is that, at least when transitioning, rustc would
 implement the `Interner` trait and would map from the [`TyKind`]
 enum to chalk's `TyKind` on the fly, when `data()` is invoked.
 
 [`TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
 
-This section describes how each of rustc's variants can be mapped to
-Chalk variants.
-
 | rustc type | chalk variant (and some notes) |
 | ------------- | ------------------ |
-| `Bool` | `Apply` |
-| `Char` | `Apply` |
-| `Int(_)` | `Apply` |
-| `Uint(_)` | `Apply` |
-| `Float(_)` | `Apply` |
-| `Adt(_, _)` | `Apply` |
-| `Foreign(_)` | `Apply` |
-| `Str` | `Apply` |
-| `Array(_, _)` | `Apply` |
-| `Slice(_)` | `Apply` |
-| `RawPtr(_)` | `Apply` |
-| `Ref(_, _, _)` | `Apply` |
-| `FnDef(_, _)` | `Apply` |
-| `FnPtr(_, _)` | `Fn` |
-| `Dynamic(_, _)` | `Dyn` |
-| `Closure(_, _)` | `Apply` |
-| `Generator(_, _)` | `Apply` |
-| `GeneratorWitness(_)` | `GeneratorWitness` |
-| `Never` | `Apply` |
-| `Tuple(_)` | `Apply` |
-| `Projection(_)` | `Alias` |
-| `UnnormalizedProjection(_)` | (see below) |
-| `Opaque(_, _)` | `Alias` |
-| `Param(_)` | XXX Placeholder? |
-| `Bound(_, _)` | `BoundVariable` |
-| `Placeholder(_)` | `Placeholder` |
-| `Infer(_)` | `InferenceVar` |
+| `Bool` | `Scalar` |
+| `Char` | `Scalar` |
+| `Int` | `Scalar` |
+| `Uint` | `Scalar` |
+| `Float` | `Scalar` |
+| `Adt` | `Adt` |
+| `Foreign` | `Foreign` |
+| `Str` | `Str` |
+| `Array` | `Array` |
+| `Slice` | `Slice` |
+| `RawPtr` | `Raw` |
+| `Ref` | `Ref` |
+| `FnDef` | `FnDef` |
+| `FnPtr` | `Function` |
+| `Dynamic` | `Dyn` |
+| `Closure` | `Closure` |
+| `Generator` | `Generator` |
+| `GeneratorWitness` | `GeneratorWitness` |
+| `Never` | `Never` |
+| `Tuple` | `Tuple` |
+| `Projection` | `Alias` |
+| `UnnormalizedProjection` | (see below) |
+| `Opaque` | `Alias` |
+| `Param` | XXX Placeholder? |
+| `Bound` | `BoundVar` |
+| `Placeholder` | `Placeholder` |
+| `Infer` | `InferenceVar` |
 | `Error` | `Error` |

book/src/types/rust_types/alias.md

@@ -57,13 +57,13 @@ definition, and depend a bit on the kind of alias. We describe that lowering in
 ## Alias placeholders
 
 For each kind of alias (except for explicit type aliases), there is also a
-corresponding *placeholder* variant in the [`TypeName`] enum. In those cases
+corresponding *placeholder* variant in the [`TyKind`] enum. In those cases
 where we cannot normalize the alias to something specific, it can be equated to
 the placeholder type (see e.g. [`AssociatedType`], which is the placeholder
 variant for associated type projections). Note that placeholders are
 *application types* -- unlike an alias, a placeholder is only known to be equal
 with itself, just like an application type.
 
-[`TypeName`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TypeName.html
-[`AssociatedType`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TypeName.html#variant.AssociatedType
+[`TyKind`]: https://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html
+[`AssociatedType`]: https://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html#variant.AssociatedType
 

book/src/types/rust_types/application_ty.md

@@ -1,28 +1,21 @@
 # Application types
 
-An [`ApplicationTy`] is kind of a "normal Rust type", like
-`Vec<u32>` or `f32`. Such types are only "equal" to themselves (modulo
-aliases, see below), and they may take type arguments.  Note that we
-group together *both* user-defined structs/enums/unions (like `Vec`)
+[`TyKind`] variants that consist of some type-specific info ("type name")
+and a substitution are usually referred to as application types. 
+These include most of the "normal Rust types", such as `Vec` and `(f32, u32)`.
+Such types are only "equal" to themselves (modulo aliases, see below). 
+Scalar types (and some others) also fall into this category, despite having no
+substitutions: we treat them as having zero-length substitutions.
+Note that we group together *both* user-defined structs/enums/unions (like `Vec`)
 as well as built-in types like `f32`, which effectively behave the
 same.
 
-[`ApplicationTy`]: http://rust-lang.github.io/chalk/chalk_ir/struct.ApplicationTy.html
+We used to have application types in chalk as a separate notion in the codebase,
+but have since moved away from that; nevertheless, the term is still useful in discussions.
 
-An [`ApplicationTy`] contains two fields:
+[`TyKind`]: https://rust-lang.github.io/chalk/chalk_ir/enum.TyKind.html
 
-* a "type name" (of type [`TypeName`]); and,
-* a list of generic arguments (of type [`Substitution`]).
-
-The [`TypeName`] itself is largely opaque to chalk. We discuss it in
-more detail elsewhere. The point is that it represents, semantically,
-either the name of some user-defined type (like `Vec`) or builtin-types
-like `i32`. It may also represent types like "tuple of arity 2" (`(_,
-_)`) or "fixed-length array" `[_; _]`. Note that the precise set of
-these built-in types is defined by the `Interner` and is unknown to
-chalk-ir.
-
-## [`TypeName`] variants
+## Notable application types
 
 ### Generator
 
@@ -36,10 +29,10 @@ to a generator:
   used when the generator is running.
 * Generator witness - see the `Generator Witness` section below.
 
-Of these types, only upvars and resume/yield/return are stored directly in
-`TypeName::Generator`. The generator witness is implicitly associated with the generator
-by virtue of sharing the same `GeneratorId`. It is only used when determining auto trait
-impls, where it is considered a 'constituent type'.
+Of these types, only upvars and resume/yield/return are stored directly in `GeneratorDatum`
+(which is acessed via `RustIrDatabase`). The generator witness is implicitly associated with
+the generator by virtue of sharing the same `GeneratorId`. It is only used when determining
+auto trait impls, where it is considered a 'constituent type'.
 
 ### Generator witness types
 
@@ -55,17 +48,12 @@ Unlike other types, witnesses include bound, existential
 lifetimes, which refer to lifetimes within the suspended stack frame.
 You can think of it as a type like `exists<'a> { (T...) }`.
 
-Witnesses are very similar to an `Apply` type, but it has a binder for
-the erased lifetime(s), which must be handled specifically in equating
-and so forth. In many ways, witnesses are also quite similar to `Fn`
-types, and it is not out of the question that these two could be
-unified; however, they are quite distinct semantically and so that
-would be an annoying mismatch in other parts of the system.
-Witnesses are also similar to a `Dyn` type, in that they represent an
-existential type, but in contrast to `Dyn`, what we know here is
-not a *predicate* but rather some upper bound on the set of types
-contained within.
-
-
-[`TypeName`]: http://rust-lang.github.io/chalk/chalk_ir/enum.TypeName.html
-[`Substitution`]: http://rust-lang.github.io/chalk/chalk_ir/struct.Substitution.html
+Witnesses have a binder for the erased lifetime(s), which must be
+handled specifically in equating and so forth. In many ways,
+witnesses are also quite similar to `Function` types, and it is not
+out of the question that these two could be unified; however, they
+are quite distinct semantically and so that would be an annoying
+mismatch in other parts of the system. Witnesses are also similar 
+to a `Dyn` type, in that they represent an existential type, but
+in contrast to `Dyn`, what we know here is not a *predicate* but
+rather some upper bound on the set of types contained within.