Skip to content
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.

Commit ef67b09

Browse files
committedFeb 4, 2023
Merge branch 'master' into update-bootstrap-related-docs
2 parents 245039c + 5c65222 commit ef67b09

13 files changed

+99
-57
lines changed
 

‎src/appendix/glossary.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -23,7 +23,7 @@ Term | Meaning
2323
<span id="double-ptr">double pointer</span> &nbsp; | A pointer with additional metadata. See "fat pointer" for more.
2424
<span id="drop-glue">drop glue</span> &nbsp; | (internal) compiler-generated instructions that handle calling the destructors (`Drop`) for data types.
2525
<span id="dst">DST</span> &nbsp; | Short for Dynamically-Sized Type, this is a type for which the compiler cannot statically know the size in memory (e.g. `str` or `[u8]`). Such types don't implement `Sized` and cannot be allocated on the stack. They can only occur as the last field in a struct. They can only be used behind a pointer (e.g. `&str` or `&[u8]`).
26-
<span id="ebl">early-bound lifetime</span> &nbsp; | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions))
26+
<span id="ebl">early-bound lifetime</span> &nbsp; | A lifetime region that is substituted at its definition site. Bound in an item's `Generics` and substituted using a `Substs`. Contrast with **late-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html#bound-regions))
2727
<span id="empty-type">empty type</span> &nbsp; | see "uninhabited type".
2828
<span id="fat-ptr">fat pointer</span> &nbsp; | A two word value carrying the address of some value, along with some further information necessary to put the value to use. Rust includes two kinds of "fat pointers": references to slices, and trait objects. A reference to a slice carries the starting address of the slice and its length. A trait object carries a value's address and a pointer to the trait's implementation appropriate to that value. "Fat pointers" are also known as "wide pointers", and "double pointers".
2929
<span id="free-var">free variable</span> &nbsp; | A "free variable" is one that is not bound within an expression or term; see [the background chapter for more](./background.md#free-vs-bound)
@@ -42,7 +42,7 @@ Term | Meaning
4242
<span id="irlo">IRLO</span> &nbsp; | `IRLO` or `irlo` is sometimes used as an abbreviation for [internals.rust-lang.org](https://internals.rust-lang.org).
4343
<span id="item">item</span> &nbsp; | A kind of "definition" in the language, such as a static, const, use statement, module, struct, etc. Concretely, this corresponds to the `Item` type.
4444
<span id="lang-item">lang item</span> &nbsp; | Items that represent concepts intrinsic to the language itself, such as special built-in traits like `Sync` and `Send`; or traits representing operations such as `Add`; or functions that are called by the compiler. ([see more](https://doc.rust-lang.org/1.9.0/book/lang-items.html))
45-
<span id="lbl">late-bound lifetime</span> &nbsp; | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#bound-regions))
45+
<span id="lbl">late-bound lifetime</span> &nbsp; | A lifetime region that is substituted at its call site. Bound in a HRTB and substituted by specific functions in the compiler, such as `liberate_late_bound_regions`. Contrast with **early-bound lifetime**. ([see more](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html#bound-regions))
4646
<span id="local-crate">local crate</span> &nbsp; | The crate currently being compiled. This is in contrast to "upstream crates" which refer to dependencies of the local crate.
4747
<span id="lto">LTO</span> &nbsp; | Short for Link-Time Optimizations, this is a set of optimizations offered by LLVM that occur just before the final binary is linked. These include optimizations like removing functions that are never used in the final program, for example. _ThinLTO_ is a variant of LTO that aims to be a bit more scalable and efficient, but possibly sacrifices some optimizations. You may also read issues in the Rust repo about "FatLTO", which is the loving nickname given to non-Thin LTO. LLVM documentation: [here][lto] and [here][thinlto].
4848
<span id="llvm">[LLVM]</span> &nbsp; | (actually not an acronym :P) an open-source compiler backend. It accepts LLVM IR and outputs native binaries. Various languages (e.g. Rust) can then implement a compiler front-end that outputs LLVM IR and use LLVM to compile to all the platforms LLVM supports.

‎src/borrow_check/region_inference/lifetime_parameters.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -43,8 +43,8 @@ only variant of [`ty::RegionKind`] that we use is the [`ReVar`]
4343
variant. These region variables are broken into two major categories,
4444
based on their index:
4545

46-
[`ty::RegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html
47-
[`ReVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.RegionKind.html#variant.ReVar
46+
[`ty::RegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html
47+
[`ReVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.RegionKind.html#variant.ReVar
4848

4949
- 0..N: universal regions -- the ones we are discussing here. In this
5050
case, the code must be correct with respect to any value of those

‎src/building/bootstrapping.md

+9-5
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,6 @@
22

33
<!-- toc -->
44

5-
65
[*Bootstrapping*][boot] is the process of using a compiler to compile itself.
76
More accurately, it means using an older compiler to compile a newer version
87
of the same compiler.
@@ -16,6 +15,11 @@ version.
1615
This is exactly how `x.py` works: it downloads the current beta release of
1716
rustc, then uses it to compile the new compiler.
1817

18+
Note that this documentation mostly covers user-face informations. See
19+
[bootstrap/README.md][bootstrap-internals] to read bootstrap internals.
20+
21+
[bootstrap-internals]: https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md
22+
1923
## Stages of bootstrapping
2024

2125
Compiling `rustc` is done in stages. Here's a diagram, adapted from Joshua Nelson's
@@ -389,7 +393,7 @@ variables.
389393
[cc-rs crate]: https://github.com/rust-lang/cc-rs
390394
[env-vars]: https://github.com/rust-lang/cc-rs#external-configuration-via-environment-variables
391395

392-
### Clarification of build command's stdout
396+
## Clarification of build command's stdout
393397

394398
In this part, we will investigate the build command's stdout in an action
395399
(similar, but more detailed and complete documentation compare to topic above).
@@ -408,17 +412,17 @@ Building stage1 tool rust-analyzer-proc-macro-srv (x86_64-unknown-linux-gnu)
408412
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
409413
```
410414

411-
#### Building stage0 {std,compiler} artifacts
415+
### Building stage0 {std,compiler} artifacts
412416

413417
These steps use the provided (downloaded, usually) compiler to compile the
414418
local Rust source into libraries we can use.
415419

416-
#### Copying stage0 {std,rustc}
420+
### Copying stage0 {std,rustc}
417421

418422
This copies the library and compiler artifacts from Cargo into
419423
`stage0-sysroot/lib/rustlib/{target-triple}/lib`
420424

421-
#### Assembling stage1 compiler
425+
### Assembling stage1 compiler
422426

423427
This copies the libraries we built in "building stage0 ... artifacts" into
424428
the stage1 compiler's lib directory. These are the host libraries that the

‎src/building/how-to-build-and-run.md

+2-8
Original file line numberDiff line numberDiff line change
@@ -122,16 +122,10 @@ you will likely need to build at some point; for example, if you want
122122
to run the entire test suite).
123123

124124
```bash
125-
rustup toolchain link stage1 build/<host-triple>/stage1
126-
rustup toolchain link stage2 build/<host-triple>/stage2
125+
rustup toolchain link stage1 build/host/stage1
126+
rustup toolchain link stage2 build/host/stage2
127127
```
128128

129-
The `<host-triple>` would typically be one of the following:
130-
131-
- Linux: `x86_64-unknown-linux-gnu`
132-
- Mac: `x86_64-apple-darwin` or `aarch64-apple-darwin`
133-
- Windows: `x86_64-pc-windows-msvc`
134-
135129
Now you can run the `rustc` you built with. If you run with `-vV`, you
136130
should see a version number ending in `-dev`, indicating a build from
137131
your local environment:

‎src/building/suggested.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -34,7 +34,7 @@ you can write: <!-- date-check: nov 2022 --><!-- the date comment is for the edi
3434
"--json-output"
3535
],
3636
"rust-analyzer.rustfmt.overrideCommand": [
37-
"./build/host/stage0/bin/rustfmt",
37+
"./build/host/rustfmt/bin/rustfmt",
3838
"--edition=2021"
3939
],
4040
"rust-analyzer.procMacro.server": "./build/host/stage0/libexec/rust-analyzer-proc-macro-srv",

‎src/constants.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -78,5 +78,5 @@ the constant doesn't use them in any way. This can cause
7878

7979
[`ty::Const`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Const.html
8080
[`ty::ConstKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.ConstKind.html
81-
[`ty::TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
81+
[`ty::TyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html
8282
[pcg-unused-substs]: https://github.com/rust-lang/project-const-generics/issues/33

‎src/implementing_new_features.md

+1-1
Original file line numberDiff line numberDiff line change
@@ -33,7 +33,7 @@ like this; for example, the compiler team recommends
3333
filing a Major Change Proposal ([MCP][mcp]) as a lightweight way to
3434
garner support and feedback without requiring full consensus.
3535

36-
[mcp]: compiler/mcp.md#public-facing-changes-require-rfcbot-fcp
36+
[mcp]: https://forge.rust-lang.org/compiler/mcp.html#public-facing-changes-require-rfcbot-fcp
3737

3838
You don't need to have the implementation fully ready for r+ to propose an FCP,
3939
but it is generally a good idea to have at least a proof

‎src/llvm-coverage-instrumentation.md

+3-4
Original file line numberDiff line numberDiff line change
@@ -299,11 +299,10 @@ $ ./x.py test tests/run-make-fulldeps/coverage --bless
299299
```
300300

301301
[mir-opt-test]: https://github.com/rust-lang/rust/blob/master/tests/mir-opt/instrument_coverage.rs
302-
[coverage-test-samples]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage
303-
[`coverage-reports`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-reports
304-
[`coverage-spanview`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-spanview
302+
[coverage-test-samples]: https://github.com/rust-lang/rust/tree/master/tests/run-make/coverage
303+
[`coverage-reports`]: https://github.com/rust-lang/rust/tree/master/tests/run-make/coverage-reports
305304
[spanview-debugging]: compiler-debugging.md#viewing-spanview-output
306-
[`coverage-llvmir`]: https://github.com/rust-lang/rust/tree/master/tests/run-make-fulldeps/coverage-llvmir
305+
[`coverage-llvmir`]: https://github.com/rust-lang/rust/tree/master/tests/run-make/coverage-llvmir
307306

308307
## Implementation Details of the `InstrumentCoverage` MIR Pass
309308

‎src/mir/visitor.md

+3-3
Original file line numberDiff line numberDiff line change
@@ -37,10 +37,10 @@ code that will execute whenever a `foo` is found. If you want to
3737
recursively walk the contents of the `foo`, you then invoke the
3838
`super_foo` method. (NB. You never want to override `super_foo`.)
3939

40-
A very simple example of a visitor can be found in [`LocalUseCounter`].
41-
By implementing `visit_local` method, this visitor counts how many times each local is used.
40+
A very simple example of a visitor can be found in [`LocalUseVisitor`].
41+
By implementing `visit_local` method, this visitor counts how many times each local is mutably used.
4242

43-
[`LocalUseCounter`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/simplify_try/struct.LocalUseCounter.html
43+
[`LocalUseVisitor`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/const_debuginfo/struct.LocalUseVisitor.html
4444

4545
## Traversal
4646

‎src/profiling/with_perf.md

+6-5
Original file line numberDiff line numberDiff line change
@@ -90,14 +90,15 @@ You can also use that same command to use cachegrind or other profiling tools.
9090

9191
If you prefer to run things manually, that is also possible. You first
9292
need to find the source for the test you want. Sources for the tests
93-
are found in [the `collector/benchmarks` directory][dir]. So let's go
94-
into the directory of a specific test; we'll use `clap-rs` as an
95-
example:
93+
are found in [the `collector/compile-benchmarks` directory][compile-time dir]
94+
and [the `collector/runtime-benchmarks` directory][runtime dir]. So let's
95+
go into the directory of a specific test; we'll use `clap-rs` as an example:
9696

97-
[dir]: https://github.com/rust-lang/rustc-perf/tree/master/collector/benchmarks
97+
[compile-time dir]: https://github.com/rust-lang/rustc-perf/tree/master/collector/compile-benchmarks
98+
[runtime dir]: https://github.com/rust-lang/rustc-perf/tree/master/collector/runtime-benchmarks
9899

99100
```bash
100-
cd collector/benchmarks/clap-rs
101+
cd collector/compile-benchmarks/clap-3.1.6
101102
```
102103

103104
In this case, let's say we want to profile the `cargo check`

‎src/solve/the-solver.md

+2-2
Original file line numberDiff line numberDiff line change
@@ -12,6 +12,6 @@ While the actual solver is not fully pure to deal with overflow and cycles, we a
1212
going to defer that for now.
1313

1414
To deal with inference variables and to improve caching, we use
15-
[canonicalization](/canonicalization.html).
15+
[canonicalization](./canonicalization.md).
1616

17-
TODO: write the remaining code for this as well.
17+
TODO: write the remaining code for this as well.

‎src/solve/trait-solving.md

+5-5
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22

33
This chapter describes how trait solving works with the new WIP solver located in
44
[`rustc_trait_selection/solve`][solve]. Feel free to also look at the docs for
5-
[the current solver](../traits/resolution.hmtl) and [the chalk solver](./chalk.html)
5+
[the current solver](../traits/resolution.md) and [the chalk solver](../traits/chalk.md)
66
can be found separately.
77

88
## Core concepts
@@ -29,7 +29,7 @@ have to prove and the `param_env` in which this predicate has to hold.
2929
We prove goals by checking whether each possible [`Candidate`] applies for the given goal by
3030
recursively proving its nested goals. For a list of possible candidates with examples, look at
3131
[`CandidateSource`]. The most important candidates are `Impl` candidates, i.e. trait implementations
32-
written by the user, and `ParamEnv` candidates, i.e. assumptions in our current environment.
32+
written by the user, and `ParamEnv` candidates, i.e. assumptions in our current environment.
3333

3434
Looking at the above example, to prove `Vec<T>: Clone` we first use
3535
`impl<T: Clone> Clone for Vec<T>`. To use this impl we have to prove the nested
@@ -64,7 +64,7 @@ We can however get overflow as in the following snippet:
6464
fn foo<T: Trait>(x: )
6565
```
6666

67-
### 3. Trait goals in empty environments are proven by a unique impl.
67+
### 3. Trait goals in empty environments are proven by a unique impl
6868

6969
If a trait goal holds with an empty environment, there is a unique `impl`,
7070
either user-defined or builtin, which is used to prove that goal.
@@ -110,5 +110,5 @@ Two types being equal in the type system must mean that they have the same `Type
110110
[`Goal`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/struct.Goal.html
111111
[`Predicate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Predicate.html
112112
[`Candidate`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/assembly/struct.Candidate.html
113-
[`CandidateSource`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/trait_goals/enum.CandidateSource.html
114-
[`CanonicalResponse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/type.CanonicalResponse.html
113+
[`CandidateSource`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/assembly/enum.CandidateSource.html
114+
[`CanonicalResponse`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_trait_selection/solve/type.CanonicalResponse.html

‎src/ty.md

+62-18
Original file line numberDiff line numberDiff line change
@@ -133,7 +133,7 @@ the `ty::Ty` to be a thin pointer-like
133133
type. This allows us to do cheap comparisons for equality, along with the other
134134
benefits of interning.
135135

136-
[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html
136+
[tykind]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html
137137

138138
## Allocating and working with types
139139

@@ -148,18 +148,62 @@ These methods all return a `Ty<'tcx>` – note that the lifetime you get back is
148148
arena that this `tcx` has access to. Types are always canonicalized and interned (so we never
149149
allocate exactly the same type twice).
150150

151-
> N.B.
152-
> Because types are interned, it is possible to compare them for equality efficiently using `==`
153-
> – however, this is almost never what you want to do unless you happen to be hashing and looking
154-
> for duplicates. This is because often in Rust there are multiple ways to represent the same type,
155-
> particularly once inference is involved. If you are going to be testing for type equality, you
156-
> probably need to start looking into the inference code to do it right.
157-
158151
You can also find various common types in the `tcx` itself by accessing its fields:
159152
`tcx.types.bool`, `tcx.types.char`, etc. (See [`CommonTypes`] for more.)
160153

161154
[`CommonTypes`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/context/struct.CommonTypes.html
162155

156+
<!-- N.B: This section is linked from the type comparison internal lint. -->
157+
## Comparing types
158+
159+
Because types are interned, it is possible to compare them for equality efficiently using `==`
160+
– however, this is almost never what you want to do unless you happen to be hashing and looking
161+
for duplicates. This is because often in Rust there are multiple ways to represent the same type,
162+
particularly once inference is involved.
163+
164+
For example, the type `{integer}` (`ty::Infer(ty::IntVar(..))` an integer inference variable,
165+
the type of an integer literal like `0`) and `u8` (`ty::UInt(..)`) should often be treated as
166+
equal when testing whether they can be assigned to each other (which is a common operation in
167+
diagnostics code). `==` on them will return `false` though, since they are different types.
168+
169+
The simplest way to compare two types correctly requires an inference context (`infcx`).
170+
If you have one, you can use `infcx.can_eq(param_env, ty1, ty2)`
171+
to check whether the types can be made equal.
172+
This is typically what you want to check during diagnostics, which is concerned with questions such
173+
as whether two types can be assigned to each other, not whether they're represented identically in
174+
the compiler's type-checking layer.
175+
176+
When working with an inference context, you have to be careful to ensure that potential inference
177+
variables inside the types actually belong to that inference context. If you are in a function
178+
that has access to an inference context already, this should be the case. Specifically, this is the
179+
case during HIR type checking or MIR borrow checking.
180+
181+
Another consideration is normalization. Two types may actually be the same, but one is behind an
182+
associated type. To compare them correctly, you have to normalize the types first. This is
183+
primarily a concern during HIR type checking and with all types from a `TyCtxt` query
184+
(for example from `tcx.type_of()`).
185+
186+
When a `FnCtxt` or an `ObligationCtxt` is available during type checking, `.normalize(ty)`
187+
should be used on them to normalize the type. After type checking, diagnostics code can use
188+
`tcx.normalize_erasing_regions(ty)`.
189+
190+
There are also cases where using `==` on `Ty` is fine. This is for example the case in late lints
191+
or after monomorphization, since type checking has been completed, meaning all inference variables
192+
are resolved and all regions have been erased. In these cases, if you know that inference variables
193+
or normalization won't be a concern, `#[allow]` or `#[expect]`ing the lint is recommended.
194+
195+
When diagnostics code does not have access to an inference context, it should be threaded through
196+
the function calls if one is available in some place (like during type checking).
197+
198+
If no inference context is available at all, then one can be created as described in
199+
[type-inference]. But this is only useful when the involved types (for example, if
200+
they came from a query like `tcx.type_of()`) are actually substituted with fresh
201+
inference variables using [`fresh_substs_for_item`]. This can be used to answer questions
202+
like "can `Vec<T>` for any `T` be unified with `Vec<u32>`?".
203+
204+
[type-inference]: ./type-inference.md#creating-an-inference-context
205+
[`fresh_substs_for_item`]: https://doc.rust-lang.org/beta/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.fresh_substs_for_item
206+
163207
## `ty::TyKind` Variants
164208

165209
Note: `TyKind` is **NOT** the functional programming concept of *Kind*.
@@ -207,16 +251,16 @@ There are many variants on the `TyKind` enum, which you can see by looking at it
207251
- [**And many more**...][kindvars]
208252

209253
[wikiadt]: https://en.wikipedia.org/wiki/Algebraic_data_type
210-
[kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Adt
211-
[kindforeign]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Foreign
212-
[kindstr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Str
213-
[kindslice]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Slice
214-
[kindarray]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Array
215-
[kindrawptr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.RawPtr
216-
[kindref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Ref
217-
[kindparam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Param
218-
[kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variant.Error
219-
[kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.TyKind.html#variants
254+
[kindadt]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Adt
255+
[kindforeign]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Foreign
256+
[kindstr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Str
257+
[kindslice]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Slice
258+
[kindarray]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Array
259+
[kindrawptr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.RawPtr
260+
[kindref]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Ref
261+
[kindparam]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Param
262+
[kinderr]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variant.Error
263+
[kindvars]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_type_ir/sty/enum.TyKind.html#variants
220264

221265
## Import conventions
222266

0 commit comments

Comments
 (0)
Please sign in to comment.