Skip to content

Commit 3af2f12

Browse files
committed
docs: spelling and grammar fixes
1 parent 0fe0d89 commit 3af2f12

File tree

5 files changed

+9
-9
lines changed

5 files changed

+9
-9
lines changed

src/doc/contrib/src/implementation/schemas.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@ Generally,
1515
- Fields should only be present when needed, saving space and parse time
1616
- Also, we can always switch to always outputting the fields but its harder to stop outputting them
1717
- `#[serde(skip_serializing_if = "Default::default")]` should be applied liberally
18-
- For output, prefer [jsonlines](https://jsonlines.org/) as it allows streaming output and flexibility to mix content (e.g. adding diagnostics to output that didn't prevously have it
18+
- For output, prefer [jsonlines](https://jsonlines.org/) as it allows streaming output and flexibility to mix content (e.g. adding diagnostics to output that didn't previously have it
1919
- `#[serde(deny_unknown_fields)]` should not be used to allow evolution of formats, including feature gating
2020

2121
## Schema Evolution Strategies

src/doc/contrib/src/process/rfc.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -42,18 +42,18 @@ When adding a table to a manifest,
4242
- Should it be inheritable?
4343
- Ensure the package table and the inheritable table under `workspace` align
4444
- Care is needed to ensure a `workspace = true` field doesn't conflict with other entries
45-
- e.g. [RFC 3389] had to explicitly exclude ever supporing a `workspace` linter
45+
- e.g. [RFC 3389] had to explicitly exclude ever supporting a `workspace` linter
4646

4747
When adding a field,
4848
- Is it inheritable?
49-
- Consider whether sharing of the field would be driven by requirements or is a manifestion of the current implementation.
49+
- Consider whether sharing of the field would be driven by requirements or is a manifestation of the current implementation.
5050
For example, in most cases, dependency sources (e.g. `version` field) should be aligned across a workspace
5151
However, frequently dependency `features` will vary across a workspace.
5252
- When inheriting, can specify it in your package?
5353
- How does specifying a field in both `workspace` and a package interact?
5454
- e.g. dependency sources cannot be overridden
5555
- e.g. dependency `features` get merged
56-
- e.g. depedency `default-features` has been hard to get right ([#12162][cargo#12162])
56+
- e.g. dependency `default-features` has been hard to get right ([#12162][cargo#12162])
5757

5858
When working extending `dependencies` tables:
5959
- How does this affect `cargo add` or `cargo remove`?

src/doc/contrib/src/tests/crater.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -38,7 +38,7 @@ Roughly the steps are:
3838
git commit
3939
```
4040

41-
5. Create an PR on rust-lang/rust.
41+
5. Create a PR on rust-lang/rust.
4242

4343
Push your submodule changes to GitHub and make a PR.
4444
Start the PR title with `[EXPERIMENT]` to make it clear what the PR is for and assign yourself or @ghost.

src/doc/src/CHANGELOG.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -950,7 +950,7 @@
950950
[#14211](https://github.com/rust-lang/cargo/pull/14211)
951951
- Use `std::fs::absolute` instead of reimplementing it
952952
[#14075](https://github.com/rust-lang/cargo/pull/14075)
953-
- Remove unecessary feature activations from cargo.
953+
- Remove unnecessary feature activations from cargo.
954954
[#14122](https://github.com/rust-lang/cargo/pull/14122)
955955
[#14160](https://github.com/rust-lang/cargo/pull/14160)
956956
- Revert #13630 as rustc ignores `-C strip` on MSVC.
@@ -3172,7 +3172,7 @@
31723172

31733173
### Nightly only
31743174

3175-
- Implemented a initial support of asymmetric token authentication for registries.
3175+
- Implemented initial support of asymmetric token authentication for registries.
31763176
([RFC 3231](https://github.com/rust-lang/rfcs/blob/master/text/3231-cargo-asymmetric-tokens.md))
31773177
([docs](https://doc.rust-lang.org/nightly/cargo/reference/unstable.html#registry-auth))
31783178
[#10771](https://github.com/rust-lang/cargo/pull/10771)
@@ -3306,7 +3306,7 @@
33063306
[#11227](https://github.com/rust-lang/cargo/pull/11227)
33073307
- Added support for git dependencies having git submodules with relative paths.
33083308
[#11106](https://github.com/rust-lang/cargo/pull/11106)
3309-
- Cargo now sends requests with a `Accept-Encoding` header to registries.
3309+
- Cargo now sends requests with an `Accept-Encoding` header to registries.
33103310
[#11292](https://github.com/rust-lang/cargo/pull/11292)
33113311
- Cargo now forwards non-UTF8 arguments to external subcommands.
33123312
[#11118](https://github.com/rust-lang/cargo/pull/11118)

src/doc/src/reference/resolver.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -189,7 +189,7 @@ These incompatibilities usually manifest as a compile-time error, but
189189
sometimes they will only appear as a runtime misbehavior. For example, let's
190190
say there is a common library named `foo` that ends up appearing with both
191191
version `1.0.0` and `2.0.0` in the resolve graph. If [`downcast_ref`] is used
192-
on a object created by a library using version `1.0.0`, and the code calling
192+
on an object created by a library using version `1.0.0`, and the code calling
193193
`downcast_ref` is downcasting to a type from version `2.0.0`, the downcast
194194
will fail at runtime.
195195

0 commit comments

Comments
 (0)