From d6d1e2eda69e70d30fe36cfa80ae30f4bc103f17 Mon Sep 17 00:00:00 2001 From: Ryan Mehri Date: Tue, 17 Dec 2024 20:35:46 -0700 Subject: [PATCH 1/2] Fix some typos --- src/asm.md | 2 +- .../opaque-types-region-inference-restrictions.md | 4 ++-- src/borrow_check/region_inference/lifetime_parameters.md | 2 +- src/building/bootstrapping/what-bootstrapping-does.md | 2 +- src/building/how-to-build-and-run.md | 2 +- src/coherence.md | 2 +- src/diagnostics.md | 2 +- src/pat-exhaustive-checking.md | 2 +- src/profiling/with_perf.md | 2 +- src/tests/adding.md | 2 +- src/tests/running.md | 4 ++-- src/ty_module/binders.md | 2 +- src/ty_module/instantiating_binders.md | 4 ++-- 13 files changed, 16 insertions(+), 16 deletions(-) diff --git a/src/asm.md b/src/asm.md index 677a08910..eec9d448b 100644 --- a/src/asm.md +++ b/src/asm.md @@ -108,7 +108,7 @@ multiple output places where a `Call` only has a single return place output. Operands are lowered one more time before being passed to LLVM codegen, this is represented by the [`InlineAsmOperandRef` type][inline_asm_codegen] from `rustc_codegen_ssa`. -The operands are lowered to LLVM operands and constraint codes as follow: +The operands are lowered to LLVM operands and constraint codes as follows: - `out` and the output part of `inout` operands are added first, as required by LLVM. Late output operands have a `=` prefix added to their constraint code, non-late output operands have a `=&` prefix added to their constraint code. diff --git a/src/borrow_check/opaque-types-region-inference-restrictions.md b/src/borrow_check/opaque-types-region-inference-restrictions.md index 13236c842..4feca1be9 100644 --- a/src/borrow_check/opaque-types-region-inference-restrictions.md +++ b/src/borrow_check/opaque-types-region-inference-restrictions.md @@ -229,8 +229,8 @@ fn test::{closure#0}(_upvar: &'?8 str) -> Opaque<'?6, '?7> { // "hidden type captures lifetime that does not appear in bounds". ``` -Without this restrictions error messages are consfusing and, more impotantly, there is a risk that -we accept code the we would likely break in the future because member constraints are super broken +Without this restrictions error messages are confusing and, more importantly, there is a risk that +we accept code that would likely break in the future because member constraints are super broken in closures. **Output types:** diff --git a/src/borrow_check/region_inference/lifetime_parameters.md b/src/borrow_check/region_inference/lifetime_parameters.md index d3e2c7626..fadfac404 100644 --- a/src/borrow_check/region_inference/lifetime_parameters.md +++ b/src/borrow_check/region_inference/lifetime_parameters.md @@ -29,7 +29,7 @@ various universal regions in scope on a particular function. We also create a [`UniversalRegionRelations`] struct, which tracks their relationships to one another. So if you have e.g. `where 'a: 'b`, then the [`UniversalRegionRelations`] struct would track that `'a: 'b` is -known to hold (which could be tested with the [`outlives`] function. +known to hold (which could be tested with the [`outlives`] function). [`UniversalRegions`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/universal_regions/struct.UniversalRegions.html [`UniversalRegionRelations`]: https://doc.rust-lang.org/nightly/nightly-rustc/rustc_borrowck/type_check/free_region_relations/struct.UniversalRegionRelations.html diff --git a/src/building/bootstrapping/what-bootstrapping-does.md b/src/building/bootstrapping/what-bootstrapping-does.md index 7d269ffa1..1dd5402f4 100644 --- a/src/building/bootstrapping/what-bootstrapping-does.md +++ b/src/building/bootstrapping/what-bootstrapping-does.md @@ -290,7 +290,7 @@ recently changed. When you build a project with `cargo`, the build artifacts for dependencies are normally stored in `target/debug/deps`. This only contains dependencies `cargo` knows about; in particular, it doesn't have the standard library. Where do `std` -or `proc_macro` come from? They comes from the **sysroot**, the root of a number +or `proc_macro` come from? They come from the **sysroot**, the root of a number of directories where the compiler loads build artifacts at runtime. The `sysroot` doesn't just store the standard library, though - it includes anything that needs to be loaded at runtime. That includes (but is not limited to): diff --git a/src/building/how-to-build-and-run.md b/src/building/how-to-build-and-run.md index 724aab847..f9a089c23 100644 --- a/src/building/how-to-build-and-run.md +++ b/src/building/how-to-build-and-run.md @@ -394,7 +394,7 @@ space, possibly around 100GB. This is compounded if you have a separate build di rust-analyzer (e.g. `build-rust-analyzer`). This is easy to hit with dev-desktops which have a [set disk quota](https://github.com/rust-lang/simpleinfra/blob/8a59e4faeb75a09b072671c74a7cb70160ebef50/ansible/roles/dev-desktop/defaults/main.yml#L7) -for each user, but this also applies to local development as well. Occassionally, you may need to: +for each user, but this also applies to local development as well. Occasionally, you may need to: - Remove `build/` directory. - Remove `build-rust-analyzer/` directory (if you have a separate rust-analyzer build directory). diff --git a/src/coherence.md b/src/coherence.md index 2d2fb7cf1..b3af101fb 100644 --- a/src/coherence.md +++ b/src/coherence.md @@ -24,7 +24,7 @@ Overlap checks are performed for both inherent impls, and for trait impls. This uses the same overlap checking code, really done as two separate analyses. Overlap checks always consider pairs of implementations, comparing them to each other. -Overlap checking for inherent impl blocks is done through `fn check_item` in coherence/inherent_impls_overlap.rs), +Overlap checking for inherent impl blocks is done through `fn check_item` (in coherence/inherent_impls_overlap.rs), where you can very clearly see that (at least for small `n`), the check really performs `n^2` comparisons between impls. diff --git a/src/diagnostics.md b/src/diagnostics.md index 71f58b482..ccd101165 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -413,7 +413,7 @@ contexts: some heuristics for verbosity are met) - shown as a `help` sub-diagnostic with no content (used for cases where the suggestion is obvious from the text, but we still want to let tools to apply -them)) +them) - not shown (used for _very_ obvious cases, but we still want to allow tools to apply them) diff --git a/src/pat-exhaustive-checking.md b/src/pat-exhaustive-checking.md index 9d20d81ba..4a796ac95 100644 --- a/src/pat-exhaustive-checking.md +++ b/src/pat-exhaustive-checking.md @@ -88,7 +88,7 @@ That file contains a detailed description of the algorithm. ### Constructors and fields In the value `Pair(Some(0), true)`, `Pair` is called the constructor of the value, and `Some(0)` and -`true` are its fields. Every matcheable value can be decomposed in this way. Examples of +`true` are its fields. Every matchable value can be decomposed in this way. Examples of constructors are: `Some`, `None`, `(,)` (the 2-tuple constructor), `Foo {..}` (the constructor for a struct `Foo`), and `2` (the constructor for the number `2`). diff --git a/src/profiling/with_perf.md b/src/profiling/with_perf.md index ea3a051a0..6cd98f886 100644 --- a/src/profiling/with_perf.md +++ b/src/profiling/with_perf.md @@ -263,7 +263,7 @@ What happens with `--tree-callees` is that to build up a call tree The `--tree-min-percent 3` option says "only show me things that take -more than 3% of the time. Without this, the tree often gets really +more than 3% of the time". Without this, the tree often gets really noisy and includes random stuff like the innards of malloc. `--tree-max-depth` can be useful too, it just limits how many levels we print. diff --git a/src/tests/adding.md b/src/tests/adding.md index ab9f20f6b..262bbbd7f 100644 --- a/src/tests/adding.md +++ b/src/tests/adding.md @@ -196,5 +196,5 @@ These comments are very useful to others later on when your test breaks, since they often can highlight what the problem is. They are also useful if for some reason the tests need to be refactored, since they let others know which parts of the test were important. Often a test must be rewritten because it no longer -tests what is was meant to test, and then it's useful to know what it *was* +tests what it was meant to test, and then it's useful to know what it *was* meant to test exactly. diff --git a/src/tests/running.md b/src/tests/running.md index 80789b396..6ce650923 100644 --- a/src/tests/running.md +++ b/src/tests/running.md @@ -30,7 +30,7 @@ notice a change) you can use the `--force-rerun` CLI option. > **Note on requirements of external dependencies** > -> Some test suites may require external dependecies. This is especially true of +> Some test suites may require external dependencies. This is especially true of > debuginfo tests. Some debuginfo tests require a Python-enabled gdb. You can > test if your gdb install supports Python by using the `python` command from > within gdb. Once invoked you can type some Python code (e.g. `print("hi")`) @@ -78,7 +78,7 @@ Likewise, you can test a single file by passing its path: ``` `x` doesn't support running a single tool test by passing its path yet. You'll -have to use the `--test-args` argument as describled +have to use the `--test-args` argument as described [below](#running-an-individual-test). ```bash diff --git a/src/ty_module/binders.md b/src/ty_module/binders.md index 87a5fccfe..6f31103d7 100644 --- a/src/ty_module/binders.md +++ b/src/ty_module/binders.md @@ -2,7 +2,7 @@ Sometimes we define generic parameters not on an item but as part of a type or a where clauses. As an example the type `for<'a> fn(&'a u32)` or the where clause `for<'a> T: Trait<'a>` both introduce a generic lifetime named `'a`. Currently there is no stable syntax for `for` or `for` but on nightly `feature(non_lifetime_binders)` feature can be used to write where clauses (but not types) using `for`/`for`. -The `for` is referred to as a "binder" because it brings new names into scope. In rustc we use the `Binder` type to track where these parameters are introduced and what the parameters are (i.e. how many and whether they the parameter is a type/const/region). A type such as `for<'a> fn(&'a u32)` would be +The `for` is referred to as a "binder" because it brings new names into scope. In rustc we use the `Binder` type to track where these parameters are introduced and what the parameters are (i.e. how many and whether the parameter is a type/const/region). A type such as `for<'a> fn(&'a u32)` would be represented in rustc as: ``` Binder( diff --git a/src/ty_module/instantiating_binders.md b/src/ty_module/instantiating_binders.md index 3c127dbcf..04d56ccbc 100644 --- a/src/ty_module/instantiating_binders.md +++ b/src/ty_module/instantiating_binders.md @@ -21,7 +21,7 @@ Unlike `EarlyBinder` we typically do not instantiate `Binder` with some concrete ## Instantiating with inference variables We instantiate binders with inference variables when we are trying to infer a possible instantiation of the binder, e.g. calling higher ranked function pointers or attempting to use a higher ranked where-clause to prove some bound. For example, given the `higher_ranked_fn_ptr` from the example above, if we were to call it with `&10_u32` we would: -- Instantaite the binder with infer vars yielding a signature of `fn(&'?0 u32) -> &'?0 u32)` +- Instantiate the binder with infer vars yielding a signature of `fn(&'?0 u32) -> &'?0 u32)` - Equate the type of the provided argument `&10_u32` (&'static u32) with the type in the signature, `&'?0 u32`, inferring `'?0 = 'static` - The provided arguments were correct as we were successfully able to unify the types of the provided arguments with the types of the arguments in fn ptr signature @@ -50,7 +50,7 @@ Note: in the original example of this chapter it was mentioned that we should no You may be wondering why we have both of these variants, afterall the data stored in `Placeholder` is effectively equivalent to that of `ReBound`: something to track which binder, and an index to track which parameter the `Binder` introduced. -The main reason for this is that `Bound` is a more syntactic representation of bound variables wheras `Placeholder` is a more semantic representation. As a concrete example: +The main reason for this is that `Bound` is a more syntactic representation of bound variables whereas `Placeholder` is a more semantic representation. As a concrete example: ```rust impl<'a> Other<'a> for &'a u32 { } From e45b0a57e75d3b4bff5ade5261dc8bbf20e2b979 Mon Sep 17 00:00:00 2001 From: Tshepang Mbambo Date: Wed, 18 Dec 2024 07:54:42 +0200 Subject: [PATCH 2/2] typo, pause --- src/borrow_check/opaque-types-region-inference-restrictions.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/borrow_check/opaque-types-region-inference-restrictions.md b/src/borrow_check/opaque-types-region-inference-restrictions.md index 4feca1be9..9877dfc61 100644 --- a/src/borrow_check/opaque-types-region-inference-restrictions.md +++ b/src/borrow_check/opaque-types-region-inference-restrictions.md @@ -229,7 +229,7 @@ fn test::{closure#0}(_upvar: &'?8 str) -> Opaque<'?6, '?7> { // "hidden type captures lifetime that does not appear in bounds". ``` -Without this restrictions error messages are confusing and, more importantly, there is a risk that +Without these restrictions, error messages are confusing and, more importantly, there is a risk that we accept code that would likely break in the future because member constraints are super broken in closures.