user0/rust
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Fix typos and grammar in compiler and build documentation

Browse source 
- compiler/rustc_codegen_llvm/src/debuginfo/doc.md: fix 5 issues
  (adaption → adaptation, "allow to" → "allow V-ing" x3, later → latter + plural)
- compiler/rustc_thread_pool/src/sleep/README.md: fix 2 issues
  (idle → active per context, then → than)
- src/bootstrap/README.md: fix 2 issues (rust → Rust, add missing article "the")
- src/ci/docker/README.md: fix 2 issues ("come form" → "come from", grammar)
This commit is contained in:
ron 2026-02-10 10:22:05 -05:00
parent f21b4c0888
commit 11e4873b96
4 changed files with 11 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

10
compiler/rustc_codegen_llvm/src/debuginfo/doc.md
View file

@ -16,7 +16,7 @@ module to generate correct metadata and insert it into the LLVM IR.
As the exact format of metadata trees may change between different LLVM As the exact format of metadata trees may change between different LLVM
versions, we now use LLVM versions, we now use LLVM
[DIBuilder](https://llvm.org/docs/doxygen/html/classllvm_1_1DIBuilder.html) [DIBuilder](https://llvm.org/docs/doxygen/html/classllvm_1_1DIBuilder.html)
to create metadata where possible. This will hopefully ease the adaption of to create metadata where possible. This will hopefully ease the adaptation of
this module to future LLVM versions. this module to future LLVM versions.
The public API of the module is a set of functions that will insert the The public API of the module is a set of functions that will insert the
@ -87,19 +87,19 @@ describe the type anew. This behavior is encapsulated in the
## Source Locations and Line Information ## Source Locations and Line Information
In addition to data type descriptions the debugging information must also In addition to data type descriptions the debugging information must also
allow to map machine code locations back to source code locations in order allow mapping machine code locations back to source code locations in order
to be useful. This functionality is also handled in this module. The to be useful. This functionality is also handled in this module. The
following functions allow to control source mappings: following functions allow controlling source mappings:
+ `set_source_location()` + `set_source_location()`
+ `clear_source_location()` + `clear_source_location()`
+ `start_emitting_source_locations()` + `start_emitting_source_locations()`
`set_source_location()` allows to set the current source location. All IR `set_source_location()` allows setting the current source location. All IR
instructions created after a call to this function will be linked to the instructions created after a call to this function will be linked to the
given source location, until another location is specified with given source location, until another location is specified with
`set_source_location()` or the source location is cleared with `set_source_location()` or the source location is cleared with
`clear_source_location()`. In the later case, subsequent IR instruction `clear_source_location()`. In the latter case, subsequent IR instructions
will not be linked to any source location. As you can see, this is a will not be linked to any source location. As you can see, this is a
stateful API (mimicking the one in LLVM), so be careful with source stateful API (mimicking the one in LLVM), so be careful with source
locations set by previous calls. It's probably best to not rely on any locations set by previous calls. It's probably best to not rely on any

4
compiler/rustc_thread_pool/src/sleep/README.md
View file

@ -32,7 +32,7 @@ There are three main thread states:
waiting to be awoken. waiting to be awoken.
We sometimes refer to the final two states collectively as **inactive**. We sometimes refer to the final two states collectively as **inactive**.
Threads begin as idle but transition to idle and finally sleeping when Threads begin as active but transition to idle and finally sleeping when
they're unable to find work to do. they're unable to find work to do.
## Sleepy threads ## Sleepy threads
@ -160,7 +160,7 @@ not complete. It is possible -- if unlikely -- that enough activity occurs for
Thread A to observe the same JEC value that it saw when getting sleepy. If the Thread A to observe the same JEC value that it saw when getting sleepy. If the
new work being published came from *inside* the thread-pool, then this race new work being published came from *inside* the thread-pool, then this race
condition isn't too harmful. It means that we have fewer workers processing the condition isn't too harmful. It means that we have fewer workers processing the
work then we should, but we won't deadlock. This seems like an acceptable risk work than we should, but we won't deadlock. This seems like an acceptable risk
given that this is unlikely in practice. given that this is unlikely in practice.
However, if the work was posted as an *external* job, that is a problem. In that However, if the work was posted as an *external* job, that is a problem. In that

4
src/bootstrap/README.md
View file

@ -175,8 +175,8 @@ When you use bootstrap, you'll call it through the entry point script
(`x`, `x.ps1`, or `x.py`). However, most of the code lives in `src/bootstrap`. (`x`, `x.ps1`, or `x.py`). However, most of the code lives in `src/bootstrap`.
`bootstrap` has a difficult problem: it is written in Rust, but yet it is run `bootstrap` has a difficult problem: it is written in Rust, but yet it is run
before the Rust compiler is built! To work around this, there are two components before the Rust compiler is built! To work around this, there are two components
of bootstrap: the main one written in rust, and `bootstrap.py`. `bootstrap.py` of bootstrap: the main one written in Rust, and `bootstrap.py`. `bootstrap.py`
is what gets run by entry point script. It takes care of downloading the prebuilt is what gets run by the entry point script. It takes care of downloading the prebuilt
stage 0 compiler, std and Cargo binaries, which are then used to build the stage 0 compiler, std and Cargo binaries, which are then used to build the
bootstrap binary. bootstrap binary.

4
src/ci/docker/README.md
View file

@ -48,7 +48,7 @@ Refer to the [dev guide](https://rustc-dev-guide.rust-lang.org/tests/docker.html
## Docker Toolbox on Windows ## Docker Toolbox on Windows
For Windows before Windows 10, the docker images can be run on Windows via For Windows before Windows 10, the docker images can be run on Windows via
[Docker Toolbox]. There are several preparation needs to be made before running [Docker Toolbox]. There are several preparations that need to be made before running
a Docker image. a Docker image.
1. Stop the virtual machine from the terminal with `docker-machine stop` 1. Stop the virtual machine from the terminal with `docker-machine stop`
@ -92,7 +92,7 @@ To run the image,
A number of these images take quite a long time to compile as they're building A number of these images take quite a long time to compile as they're building
whole gcc toolchains to do cross builds with. Much of this is relatively whole gcc toolchains to do cross builds with. Much of this is relatively
self-explanatory but some images use [crosstool-ng] which isn't quite as self self-explanatory but some images use [crosstool-ng] which isn't quite as self
explanatory. Below is a description of where these `*.defconfig` files come form, explanatory. Below is a description of where these `*.defconfig` files come from,
how to generate them, and how the existing ones were generated. how to generate them, and how the existing ones were generated.
[crosstool-ng]: https://github.com/crosstool-ng/crosstool-ng [crosstool-ng]: https://github.com/crosstool-ng/crosstool-ng