use consistent title capitalization

This commit is contained in:
Tshepang Mbambo 2025-05-22 14:43:42 +02:00
parent 7d5bda0d8a
commit 1f2bdb5526
8 changed files with 28 additions and 28 deletions

View File

@ -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)
---

View File

@ -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:

View File

@ -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,

View File

@ -1,4 +1,4 @@
# LLVM Source-Based Code Coverage
# LLVM source-based code coverage
<!-- toc -->

View File

@ -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!

View File

@ -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

View File

@ -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].

View File

@ -1,4 +1,4 @@
# Sanitizers Support
# Sanitizers support
The rustc compiler contains support for following sanitizers: