linkcheck: fix reported broken links (part 1) (#2022)
This commit is contained in:
parent
9e353070a0
commit
f49f30d427
|
|
@ -243,7 +243,8 @@ use in lambda calculus evaluation (see [this Wikipedia article][wikideb] for
|
|||
more). In `rustc`, we use de Bruijn indices to [represent generic types][sub].
|
||||
|
||||
[wikideb]: https://en.wikipedia.org/wiki/De_Bruijn_index
|
||||
[sub]: ../generics.md
|
||||
[sub]: ../ty_module/generic_arguments.md
|
||||
|
||||
|
||||
Here is a basic example of how de Bruijn indices might be used for closures (we
|
||||
don't actually do this in `rustc` though!):
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ Rust, as well as publications about Rust.
|
|||
## Type system
|
||||
|
||||
* [Alias burying](https://dl.acm.org/doi/10.1002/spe.370) - We tried something similar and abandoned it.
|
||||
* [External uniqueness is unique enough](http://www.cs.uu.nl/research/techreps/UU-CS-2002-048.html)
|
||||
* [External uniqueness is unique enough](https://lirias.kuleuven.be/retrieve/35835)
|
||||
* [Macros that work together](https://www.cs.utah.edu/plt/publications/jfp12-draft-fcdf.pdf)
|
||||
* [Making ad-hoc polymorphism less ad hoc](https://dl.acm.org/doi/10.1145/75277.75283)
|
||||
* [Region based memory management in Cyclone](https://www.cs.umd.edu/projects/cyclone/papers/cyclone-regions.pdf)
|
||||
|
|
@ -84,7 +84,7 @@ Rust, as well as publications about Rust.
|
|||
* [Rust-Bio: a fast and safe bioinformatics library](https://academic.oup.com/bioinformatics/article/32/3/444/1743419). Johannes Köster
|
||||
* [Safe, Correct, and Fast Low-Level Networking](https://octarineparrot.com/assets/msci_paper.pdf). Robert Clipsham's master's thesis.
|
||||
* [Formalizing Rust traits](https://open.library.ubc.ca/cIRcle/collections/ubctheses/24/items/1.0220521). Jonatan Milewski's master's thesis.
|
||||
* [Rust as a Language for High Performance GC Implementation](https://users.cecs.anu.edu.au/~steveb/downloads/pdf/rust-ismm-2016.pdf)
|
||||
* [Rust as a Language for High Performance GC Implementation](https://dl.acm.org/doi/pdf/10.1145/3241624.2926707)
|
||||
* [Simple Verification of Rust Programs via Functional Purification](https://github.com/Kha/electrolysis). Sebastian Ullrich's master's thesis.
|
||||
* [Writing parsers like it is 2017](http://spw17.langsec.org/papers/chifflier-parsing-in-2017.pdf) Pierre Chifflier and Geoffroy Couprie for the Langsec Workshop
|
||||
* [The Case for Writing a Kernel in Rust](https://www.tockos.org/assets/papers/rust-kernel-apsys2017.pdf)
|
||||
|
|
|
|||
|
|
@ -201,7 +201,7 @@ behave more like existential lifetimes in that the relations between them are no
|
|||
time, instead their values are inferred just like existential lifetimes and the requirements are
|
||||
propagated back to the parent fn. This breaks the member constraints algorithm as described above:
|
||||
> In order for the algorithm to pick the right choice, the complete set of “outlives” relationships
|
||||
between the choice regions ['static, '?1] must already be known before doing the region inference
|
||||
between the choice regions `['static, '?1]` must already be known before doing the region inference
|
||||
|
||||
Here is an example that details how :
|
||||
|
||||
|
|
|
|||
|
|
@ -41,7 +41,7 @@ A very simple example of a visitor can be found in [`LocalFinder`].
|
|||
By implementing `visit_local` method, this visitor identifies local variables that
|
||||
can be candidates for reordering.
|
||||
|
||||
-[`LocalFinder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/prettify/struct.LocalFinder.html
|
||||
[`LocalFinder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_mir_transform/prettify/struct.LocalFinder.html
|
||||
|
||||
## Traversal
|
||||
|
||||
|
|
|
|||
|
|
@ -77,7 +77,7 @@ implementation:
|
|||
|
||||
Sanitizers are validated by code generation tests in
|
||||
[`tests/codegen/sanitize*.rs`][test-cg] and end-to-end functional tests in
|
||||
[`tests/ui/sanitize/`][test-ui] directory.
|
||||
[`tests/ui/sanitizer/`][test-ui] directory.
|
||||
|
||||
Testing sanitizer functionality requires the sanitizer runtimes (built when
|
||||
`sanitizer = true` in `config.toml`) and target providing support for particular
|
||||
|
|
@ -86,7 +86,7 @@ be ignored. This behaviour is controlled by compiletest `needs-sanitizer-*`
|
|||
directives.
|
||||
|
||||
[test-cg]: https://github.com/rust-lang/rust/tree/master/tests/codegen
|
||||
[test-ui]: https://github.com/rust-lang/rust/tree/master/tests/ui/sanitize
|
||||
[test-ui]: https://github.com/rust-lang/rust/tree/master/tests/ui/sanitizer
|
||||
|
||||
## Enabling sanitizer on a new target
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,7 @@ check whether it's in the global cache. If so, we reuse that entry. If not, we
|
|||
compute the goal and then store its result in the cache.
|
||||
|
||||
To handle incremental compilation the computation of a goal happens inside of
|
||||
[`DepGraph::with_anon_task`] which creates a new `DepNode` which depends on all queries
|
||||
[`DepGraph::with_anon_task`][`with_anon_task`] which creates a new `DepNode` which depends on all queries
|
||||
used inside of this computation. When accessing the global cache we then read this
|
||||
`DepNode`, manually adding a dependency edge to all the queries used: [source][wdn].
|
||||
|
||||
|
|
@ -110,4 +110,4 @@ We can implement this optimization in the future.
|
|||
|
||||
[zulip thread]: https://rust-lang.zulipchat.com/#narrow/stream/364551-t-types.2Ftrait-system-refactor/topic/global.20cache
|
||||
[unstable-result-ex]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/tests/ui/traits/next-solver/cycles/coinduction/incompleteness-unstable-result.rs#L4-L16
|
||||
[cycle-participants]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_middle/src/traits/solve/cache.rs#L72-L74
|
||||
[cycle-participants]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_middle/src/traits/solve/cache.rs#L72-L74
|
||||
|
|
|
|||
|
|
@ -31,7 +31,7 @@ the responses of multiple candidates. However, canonicalizing goals during evalu
|
|||
forces the new implementation to use a fixpoint algorithm when encountering cycles
|
||||
during trait solving: [source][cycle-fixpoint].
|
||||
|
||||
[canoncalization]: ./canonicalization.md
|
||||
[canonicalization]: ./canonicalization.md
|
||||
[evaluate_stack]: https://github.com/rust-lang/rust/blob/47dd709bedda8127e8daec33327e0a9d0cdae845/compiler/rustc_trait_selection/src/traits/select/mod.rs#L1232-L1237
|
||||
[cycle-fixpoint]: https://github.com/rust-lang/rust/blob/df8ac8f1d74cffb96a93ae702d16e224f5b9ee8c/compiler/rustc_trait_selection/src/solve/search_graph.rs#L382-L387
|
||||
|
||||
|
|
@ -98,7 +98,7 @@ e.g. [trait-system-refactor-initiative#76].
|
|||
|
||||
### `NormalizesTo` goals are a function
|
||||
|
||||
See the [normalizaton] chapter. We replace the expected term with an unconstrained
|
||||
See the [normalization] chapter. We replace the expected term with an unconstrained
|
||||
inference variable before computing `NormalizesTo` goals to prevent it from affecting
|
||||
normalization. This means that `NormalizesTo` goals are handled somewhat differently
|
||||
from all other goal kinds and need some additional solver support. Most notably,
|
||||
|
|
@ -106,4 +106,4 @@ their ambiguous nested goals are returned to the caller which then evaluates the
|
|||
See [#122687] for more details.
|
||||
|
||||
[#122687]: https://github.com/rust-lang/rust/pull/122687
|
||||
[normalization]: ./normalization.md
|
||||
[normalization]: ./normalization.md
|
||||
|
|
|
|||
|
|
@ -209,7 +209,7 @@ override the cache for the others. Instead, we store the images under different
|
|||
tags, identifying them with a custom hash made from the contents of all the
|
||||
Dockerfiles and related scripts.
|
||||
|
||||
[ghcr.io]: https://ghcr.io/rust-lang-ci/rust-ci
|
||||
[ghcr.io]: https://github.com/rust-lang-ci/rust/pkgs/container/rust-ci
|
||||
[Docker registry caching]: https://docs.docker.com/build/cache/backends/registry/
|
||||
|
||||
### LLVM caching with sccache
|
||||
|
|
|
|||
|
|
@ -293,7 +293,7 @@ described below:
|
|||
- `{{target}}`: The target the test is compiling for
|
||||
- Example: `x86_64-unknown-linux-gnu`
|
||||
|
||||
See [`tests/ui/commandline-argfile.rs`](https://github.com/rust-lang/rust/blob/master/tests/ui/commandline-argfile.rs)
|
||||
See [`tests/ui/commandline-argfile.rs`](https://github.com/rust-lang/rust/blob/master/tests/ui/argfile/commandline-argfile.rs)
|
||||
for an example of a test that uses this substitution.
|
||||
|
||||
[output normalization]: ui.md#normalization
|
||||
|
|
|
|||
|
|
@ -46,6 +46,6 @@ Binder(
|
|||
This would cause all kinds of issues as the region `'^1_0` refers to a binder at a higher level than the outermost binder i.e. it is an escaping bound var. The `'^1` region (also writeable as `'^0_1`) is also ill formed as the binder it refers to does not introduce a second parameter. Modern day rustc will ICE when constructing this binder due to both of those regions, in the past we would have simply allowed this to work and then ran into issues in other parts of the codebase.
|
||||
|
||||
[`Binder`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.Binder.html
|
||||
[`BoundVar]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.BoundVar.html
|
||||
[`BoundVar`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/struct.BoundVar.html
|
||||
[`BoundRegionKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundRegionKind.html
|
||||
[`BoundTyKind`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.BoundTyKind.html
|
||||
|
|
|
|||
Loading…
Reference in New Issue