use consistent title capitalization
This commit is contained in:
parent
7d5bda0d8a
commit
1f2bdb5526
|
|
@ -181,7 +181,7 @@
|
|||
- [Significant changes and quirks](./solve/significant-changes.md)
|
||||
- [`Unsize` and `CoerceUnsized` traits](./traits/unsize.md)
|
||||
- [Type checking](./type-checking.md)
|
||||
- [Method Lookup](./method-lookup.md)
|
||||
- [Method lookup](./method-lookup.md)
|
||||
- [Variance](./variance.md)
|
||||
- [Coherence checking](./coherence.md)
|
||||
- [Opaque types](./opaque-types-type-alias-impl-trait.md)
|
||||
|
|
@ -189,7 +189,7 @@
|
|||
- [Return Position Impl Trait In Trait](./return-position-impl-trait-in-trait.md)
|
||||
- [Region inference restrictions][opaque-infer]
|
||||
- [Const condition checking](./effects.md)
|
||||
- [Pattern and Exhaustiveness Checking](./pat-exhaustive-checking.md)
|
||||
- [Pattern and exhaustiveness checking](./pat-exhaustive-checking.md)
|
||||
- [Unsafety checking](./unsafety-checking.md)
|
||||
- [MIR dataflow](./mir/dataflow.md)
|
||||
- [Drop elaboration](./mir/drop-elaboration.md)
|
||||
|
|
@ -209,7 +209,7 @@
|
|||
- [Closure capture inference](./closure.md)
|
||||
- [Async closures/"coroutine-closures"](coroutine-closures.md)
|
||||
|
||||
# MIR to Binaries
|
||||
# MIR to binaries
|
||||
|
||||
- [Prologue](./part-5-intro.md)
|
||||
- [MIR optimizations](./mir/optimizations.md)
|
||||
|
|
@ -218,15 +218,15 @@
|
|||
- [Interpreter](./const-eval/interpret.md)
|
||||
- [Monomorphization](./backend/monomorph.md)
|
||||
- [Lowering MIR](./backend/lowering-mir.md)
|
||||
- [Code Generation](./backend/codegen.md)
|
||||
- [Code generation](./backend/codegen.md)
|
||||
- [Updating LLVM](./backend/updating-llvm.md)
|
||||
- [Debugging LLVM](./backend/debugging.md)
|
||||
- [Backend Agnostic Codegen](./backend/backend-agnostic.md)
|
||||
- [Implicit Caller Location](./backend/implicit-caller-location.md)
|
||||
- [Libraries and Metadata](./backend/libs-and-metadata.md)
|
||||
- [Profile-guided Optimization](./profile-guided-optimization.md)
|
||||
- [LLVM Source-Based Code Coverage](./llvm-coverage-instrumentation.md)
|
||||
- [Sanitizers Support](./sanitizers.md)
|
||||
- [Implicit caller location](./backend/implicit-caller-location.md)
|
||||
- [Libraries and metadata](./backend/libs-and-metadata.md)
|
||||
- [Profile-guided optimization](./profile-guided-optimization.md)
|
||||
- [LLVM source-based code coverage](./llvm-coverage-instrumentation.md)
|
||||
- [Sanitizers support](./sanitizers.md)
|
||||
- [Debugging support in the Rust compiler](./debugging-support-in-rustc.md)
|
||||
|
||||
---
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Implicit Caller Location
|
||||
# Implicit caller location
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
|
|
@ -8,7 +8,7 @@ adds the [`#[track_caller]`][attr-reference] attribute for functions, the
|
|||
[`caller_location`][intrinsic] intrinsic, and the stabilization-friendly
|
||||
[`core::panic::Location::caller`][wrapper] wrapper.
|
||||
|
||||
## Motivating Example
|
||||
## Motivating example
|
||||
|
||||
Take this example program:
|
||||
|
||||
|
|
@ -39,7 +39,7 @@ These error messages are achieved through a combination of changes to `panic!` i
|
|||
of `core::panic::Location::caller` and a number of `#[track_caller]` annotations in the standard
|
||||
library which propagate caller information.
|
||||
|
||||
## Reading Caller Location
|
||||
## Reading caller location
|
||||
|
||||
Previously, `panic!` made use of the `file!()`, `line!()`, and `column!()` macros to construct a
|
||||
[`Location`] pointing to where the panic occurred. These macros couldn't be given an overridden
|
||||
|
|
@ -51,7 +51,7 @@ was expanded. This function is itself annotated with `#[track_caller]` and wraps
|
|||
[`caller_location`][intrinsic] compiler intrinsic implemented by rustc. This intrinsic is easiest
|
||||
explained in terms of how it works in a `const` context.
|
||||
|
||||
## Caller Location in `const`
|
||||
## Caller location in `const`
|
||||
|
||||
There are two main phases to returning the caller location in a const context: walking up the stack
|
||||
to find the right location and allocating a const value to return.
|
||||
|
|
@ -138,7 +138,7 @@ fn main() {
|
|||
}
|
||||
```
|
||||
|
||||
### Dynamic Dispatch
|
||||
### Dynamic dispatch
|
||||
|
||||
In codegen contexts we have to modify the callee ABI to pass this information down the stack, but
|
||||
the attribute expressly does *not* modify the type of the function. The ABI change must be
|
||||
|
|
@ -156,7 +156,7 @@ probably the best we can do without modifying fully-stabilized type signatures.
|
|||
> whether we'll be called in a const context (safe to ignore shim) or in a codegen context (unsafe
|
||||
> to ignore shim). Even if we did know, the results from const and codegen contexts must agree.
|
||||
|
||||
## The Attribute
|
||||
## The attribute
|
||||
|
||||
The `#[track_caller]` attribute is checked alongside other codegen attributes to ensure the
|
||||
function:
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Libraries and Metadata
|
||||
# Libraries and metadata
|
||||
|
||||
When the compiler sees a reference to an external crate, it needs to load some
|
||||
information about that crate. This chapter gives an overview of that process,
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# LLVM Source-Based Code Coverage
|
||||
# LLVM source-based code coverage
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# From MIR to Binaries
|
||||
# From MIR to binaries
|
||||
|
||||
All of the preceding chapters of this guide have one thing in common:
|
||||
we never generated any executable machine code at all!
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Pattern and Exhaustiveness Checking
|
||||
# Pattern and exhaustiveness checking
|
||||
|
||||
In Rust, pattern matching and bindings have a few very helpful properties. The
|
||||
compiler will check that bindings are irrefutable when made and that match arms
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Profile Guided Optimization
|
||||
# Profile-guided optimization
|
||||
|
||||
<!-- toc -->
|
||||
|
||||
|
|
@ -6,7 +6,7 @@
|
|||
This chapter describes what PGO is and how the support for it is
|
||||
implemented in `rustc`.
|
||||
|
||||
## What Is Profiled-Guided Optimization?
|
||||
## What is profiled-guided optimization?
|
||||
|
||||
The basic concept of PGO is to collect data about the typical execution of
|
||||
a program (e.g. which branches it is likely to take) and then use this data
|
||||
|
|
@ -52,7 +52,7 @@ instrumentation, via the experimental option
|
|||
[`-C instrument-coverage`](./llvm-coverage-instrumentation.md), but using these
|
||||
coverage results for PGO has not been attempted at this time.
|
||||
|
||||
### Overall Workflow
|
||||
### Overall workflow
|
||||
|
||||
Generating a PGO-optimized program involves the following four steps:
|
||||
|
||||
|
|
@ -62,12 +62,12 @@ Generating a PGO-optimized program involves the following four steps:
|
|||
4. Compile the program again, this time making use of the profiling data
|
||||
(e.g. `rustc -C profile-use=merged.profdata main.rs`)
|
||||
|
||||
### Compile-Time Aspects
|
||||
### Compile-time aspects
|
||||
|
||||
Depending on which step in the above workflow we are in, two different things
|
||||
can happen at compile time:
|
||||
|
||||
#### Create Binaries with Instrumentation
|
||||
#### Create binaries with instrumentation
|
||||
|
||||
As mentioned above, the profiling instrumentation is added by LLVM.
|
||||
`rustc` instructs LLVM to do so [by setting the appropriate][pgo-gen-passmanager]
|
||||
|
|
@ -88,7 +88,7 @@ runtime are not removed [by marking the with the right export level][pgo-gen-sym
|
|||
[pgo-gen-symbols]:https://github.com/rust-lang/rust/blob/1.34.1/src/librustc_codegen_ssa/back/symbol_export.rs#L212-L225
|
||||
|
||||
|
||||
#### Compile Binaries Where Optimizations Make Use Of Profiling Data
|
||||
#### Compile binaries where optimizations make use of profiling data
|
||||
|
||||
In the final step of the workflow described above, the program is compiled
|
||||
again, with the compiler using the gathered profiling data in order to drive
|
||||
|
|
@ -106,7 +106,7 @@ LLVM does the rest (e.g. setting branch weights, marking functions with
|
|||
`cold` or `inlinehint`, etc).
|
||||
|
||||
|
||||
### Runtime Aspects
|
||||
### Runtime aspects
|
||||
|
||||
Instrumentation-based approaches always also have a runtime component, i.e.
|
||||
once we have an instrumented program, that program needs to be run in order
|
||||
|
|
@ -134,7 +134,7 @@ instrumentation artifacts show up in LLVM IR.
|
|||
[rmake-tests]: https://github.com/rust-lang/rust/tree/master/tests/run-make
|
||||
[codegen-test]: https://github.com/rust-lang/rust/blob/master/tests/codegen/pgo-instrumentation.rs
|
||||
|
||||
## Additional Information
|
||||
## Additional information
|
||||
|
||||
Clang's documentation contains a good overview on [PGO in LLVM][llvm-pgo].
|
||||
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Sanitizers Support
|
||||
# Sanitizers support
|
||||
|
||||
The rustc compiler contains support for following sanitizers:
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue