From b4940bbed6c572fd703f13ead070484f4a79cc47 Mon Sep 17 00:00:00 2001 From: Ryan Mehri Date: Tue, 14 Jan 2025 23:01:42 -0800 Subject: [PATCH] fix some more typos --- src/backend/backend-agnostic.md | 2 +- src/closure.md | 2 +- src/const-eval.md | 2 +- src/diagnostics.md | 2 +- src/opaque-types-impl-trait-inference.md | 2 +- src/solve/caching.md | 4 ++-- src/solve/invariants.md | 4 ++-- src/solve/the-solver.md | 4 ++-- src/traits/implied-bounds.md | 4 ++-- src/ty_module/binders.md | 2 +- src/ty_module/early_binder.md | 2 +- src/ty_module/param_ty_const_regions.md | 2 +- 12 files changed, 16 insertions(+), 16 deletions(-) diff --git a/src/backend/backend-agnostic.md b/src/backend/backend-agnostic.md index 3521c00f5..0f81d3cb4 100644 --- a/src/backend/backend-agnostic.md +++ b/src/backend/backend-agnostic.md @@ -45,7 +45,7 @@ heavily on other parts of the crate. The separation of the code must not affect the logic of the code nor its performance. For these reasons, the separation process involves two transformations that -have to be done at the same time for the resulting code to compile : +have to be done at the same time for the resulting code to compile: 1. replace all the LLVM-specific types by generics inside function signatures and structure definitions; diff --git a/src/closure.md b/src/closure.md index 718a0e5d7..427919cd5 100644 --- a/src/closure.md +++ b/src/closure.md @@ -157,7 +157,7 @@ The other option is to step through the code using lldb or gdb. 1. `rust-lldb build/host/stage1/bin/rustc test.rs` 2. In lldb: - 1. `b upvar.rs:134` // Setting the breakpoint on a certain line in the upvar.rs file` + 1. `b upvar.rs:134` // Setting the breakpoint on a certain line in the upvar.rs file 2. `r` // Run the program until it hits the breakpoint Let's start with [`upvar.rs`][upvar]. This file has something called diff --git a/src/const-eval.md b/src/const-eval.md index ee0269601..69329a3e0 100644 --- a/src/const-eval.md +++ b/src/const-eval.md @@ -17,7 +17,7 @@ Prominent examples are: * need to be known to check for overlapping patterns Additionally constant evaluation can be used to reduce the workload or binary -size at runtime by precomputing complex operations at compiletime and only +size at runtime by precomputing complex operations at compile time and only storing the result. All uses of constant evaluation can either be categorized as "influencing the type system" diff --git a/src/diagnostics.md b/src/diagnostics.md index ccd101165..709e9d4f8 100644 --- a/src/diagnostics.md +++ b/src/diagnostics.md @@ -111,7 +111,7 @@ Here are a few examples: their crate, making this a hard error would make refactoring and development very painful. - [future-incompatible lints]: - these are silencable lints. + these are silenceable lints. It was decided that making them fixed errors would cause too much breakage, so warnings are instead emitted, and will eventually be turned into fixed (hard) errors. diff --git a/src/opaque-types-impl-trait-inference.md b/src/opaque-types-impl-trait-inference.md index c56d51a4b..bdf4e4cd8 100644 --- a/src/opaque-types-impl-trait-inference.md +++ b/src/opaque-types-impl-trait-inference.md @@ -78,7 +78,7 @@ If that fails, we reveal the hidden type of the opaque type, but only to prove this specific trait bound, not in general. Revealing is done by invoking the `type_of` query on the `DefId` of the opaque type. The query will internally request the hidden types from the defining function(s) -and return that (see [the section on `type_of`](#Within-the-type_of-query) for more details). +and return that (see [the section on `type_of`](#within-the-type_of-query) for more details). #### Flowchart of type checking steps diff --git a/src/solve/caching.md b/src/solve/caching.md index 72b90c59b..e568d47ca 100644 --- a/src/solve/caching.md +++ b/src/solve/caching.md @@ -98,8 +98,8 @@ TODO: write this :3 [req-depth-ck]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_middle/src/traits/solve/cache.rs#L76-L86 [update-depth]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_trait_selection/src/solve/search_graph.rs#L308 [rem-depth]: https://github.com/rust-lang/rust/blob/7606c13961ddc1174b70638e934df0439b7dc515/compiler/rustc_middle/src/traits/solve/cache.rs#L124 -[^1]: This is overly restrictive: if all nested goal return the overflow response with some -availabledepth `n`, then their result should be the same for any depths smaller than `n`. +[^1]: This is overly restrictive: if all nested goals return the overflow response with some +available depth `n`, then their result should be the same for any depths smaller than `n`. We can implement this optimization in the future. [chapter on coinduction]: ./coinduction.md diff --git a/src/solve/invariants.md b/src/solve/invariants.md index c16a3aeb2..588da490a 100644 --- a/src/solve/invariants.md +++ b/src/solve/invariants.md @@ -33,7 +33,7 @@ inference variables in both the lhs and rhs, the now potentially structurally di types should still be equal to each other. Needed to prevent goals from succeeding in HIR typeck and then failing in MIR borrowck. -If this does invariant is broken MIR typeck ends up failing with an ICE. +If this invariant is broken MIR typeck ends up failing with an ICE. ### Applying inference results from a goal does not change its result ❌ @@ -91,7 +91,7 @@ it can easily result in unsoundness, e.g. [#57893](https://github.com/rust-lang/ If a trait goal holds with an empty environment, there should be a unique `impl`, either user-defined or builtin, which is used to prove that goal. This is -necessary to select a unique method. It +necessary to select a unique method. We do however break this invariant in few cases, some of which are due to bugs, some by design: diff --git a/src/solve/the-solver.md b/src/solve/the-solver.md index f7d82d117..006fb649d 100644 --- a/src/solve/the-solver.md +++ b/src/solve/the-solver.md @@ -25,7 +25,7 @@ a separate "probe", to not leak inference constraints to the other candidates. We then try to merge the assembled candidates via `EvalCtxt::merge_candidates`. -## Important concepts and design pattern +## Important concepts and design patterns ### `EvalCtxt::add_goal` @@ -64,7 +64,7 @@ eagerly instantiates `'a` with a placeholder and then recursively proves Some goals can be proven in multiple ways. In these cases we try each option in a separate "probe" and then attempt to merge the resulting responses by using `EvalCtxt::try_merge_responses`. If merging the responses fails, we use -`EvalCtxt::flounder` instead, returning ambiguity. For some goals, we try +`EvalCtxt::flounder` instead, returning ambiguity. For some goals, we try to incompletely prefer some choices over others in case `EvalCtxt::try_merge_responses` fails. diff --git a/src/traits/implied-bounds.md b/src/traits/implied-bounds.md index 911553ad3..63b09a43f 100644 --- a/src/traits/implied-bounds.md +++ b/src/traits/implied-bounds.md @@ -41,7 +41,7 @@ requirements of impls and functions as explicit predicates. These bounds are not added to the `ParamEnv` of the affected item itself. For lexical region resolution they are added using [`fn OutlivesEnvironment::with_bounds`]. -Similarly,during MIR borrowck we add them using +Similarly, during MIR borrowck we add them using [`fn UniversalRegionRelationsBuilder::add_implied_bounds`]. [We add implied bounds for the function signature and impl header in MIR borrowck][mir]. @@ -81,4 +81,4 @@ This results in multiple unsoundnesses: [#25860]: https://github.com/rust-lang/rust/issues/25860 [#84591]: https://github.com/rust-lang/rust/issues/84591 -[#100051]: https://github.com/rust-lang/rust/issues/100051 \ No newline at end of file +[#100051]: https://github.com/rust-lang/rust/issues/100051 diff --git a/src/ty_module/binders.md b/src/ty_module/binders.md index 6f31103d7..defb7cde5 100644 --- a/src/ty_module/binders.md +++ b/src/ty_module/binders.md @@ -16,7 +16,7 @@ Usages of these parameters is represented by the `RegionKind::Bound` (or `TyKind - A [`BoundVar`] which specifies which of the parameters the `Binder` introduces we are referring to. - We also sometimes store some extra information for diagnostics reasons via the [`BoundTyKind`]/[`BoundRegionKind`] but this is not important for type equality or more generally the semantics of `Ty`. (omitted from the above example) -In debug output (and also informally when talking to eachother) we tend to write these bound variables in the format of `^DebruijnIndex_BoundVar`. The above example would instead be written as `Binder(fn(&'^0_0), &[BoundVariableKind::Region])`. Sometimes when the `DebruijnIndex` is `0` we just omit it and would write `^0`. +In debug output (and also informally when talking to each other) we tend to write these bound variables in the format of `^DebruijnIndex_BoundVar`. The above example would instead be written as `Binder(fn(&'^0_0), &[BoundVariableKind::Region])`. Sometimes when the `DebruijnIndex` is `0` we just omit it and would write `^0`. Another concrete example, this time a mixture of `for<'a>` in a where clause and a type: ``` diff --git a/src/ty_module/early_binder.md b/src/ty_module/early_binder.md index e8ff3a530..d83d73c95 100644 --- a/src/ty_module/early_binder.md +++ b/src/ty_module/early_binder.md @@ -48,7 +48,7 @@ fn bar(foo: Foo) { In the compiler the `instantiate` call for this is done in [`FieldDef::ty`] ([src][field_def_ty_src]), at some point during type checking `bar` we will wind up calling `FieldDef::ty(x, &[u32, f32])` in order to obtain the type of `foo.x`. **Note on indices:** It is a bug if the index of a `Param` does not match what the `EarlyBinder` binds. For -example, if the index is out of bounds or the index index of a lifetime corresponds to a type parameter. +example, if the index is out of bounds or the index of a lifetime corresponds to a type parameter. These sorts of errors are caught earlier in the compiler during name resolution where we disallow references to generics parameters introduced by items that should not be nameable by the inner item. diff --git a/src/ty_module/param_ty_const_regions.md b/src/ty_module/param_ty_const_regions.md index e6dfe8a66..c52f0c0df 100644 --- a/src/ty_module/param_ty_const_regions.md +++ b/src/ty_module/param_ty_const_regions.md @@ -53,7 +53,7 @@ Concretely given the `ty::Generics` for the item the parameter is defined on, if The index fully defines the `Ty` and is the only part of `TyKind::Param` that matters for reasoning about the code we are compiling. -Generally we do not care what the name is and only use the index is included for diagnostics and debug logs as otherwise it would be +Generally we do not care what the name is and only use the index. The name is included for diagnostics and debug logs as otherwise it would be incredibly difficult to understand the output, i.e. `Vec: Sized` vs `Vec: Sized`. In debug output, parameter types are often printed out as `{name}/#{index}`, for example in the function `foo` if we were to debug print `Vec` it would be written as `Vec`.