Skip to content

Commit 31a0fef

Browse files
authored
Merge pull request #2929 from pnehrer/master
Fix minor typos
2 parents cbabda0 + 0e2baed commit 31a0fef

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

49 files changed

+85
-85
lines changed

text/0019-opt-in-builtin-traits.md

Lines changed: 6 additions & 6 deletions
Original file line numberDiff line numberDiff line change
@@ -80,7 +80,7 @@ people avoid `Cell` and `Rc` when not needed. Explicit opt-in
8080
threatens that future, however, because fewer types will implement
8181
`Share`, even if they are in fact threadsafe.
8282

83-
With respect to extensibility, it is partiularly worrisome that if a
83+
With respect to extensibility, it is particularly worrisome that if a
8484
library forgets to implement `Send` or `Share`, downstream clients are
8585
stuck. They cannot, for example, use a newtype wrapper, because it
8686
would be illegal to implement `Send` on the newtype. This implies that
@@ -123,7 +123,7 @@ makes them *less* built-in, but still requires custom logic in the
123123
`Safe` or `Share` are implemented.
124124

125125
After the changes I propose, the only traits which would be
126-
specicially understood by the compiler are `Copy` and `Sized`. I
126+
specifically understood by the compiler are `Copy` and `Sized`. I
127127
consider this acceptable, since those two traits are intimately tied
128128
to the core Rust type system, unlike `Send` and `Share`.
129129

@@ -198,7 +198,7 @@ that `T` implements `Foo`. This allows recursive types like
198198
struct List<T> { data: T, next: Option<List<T>> }
199199

200200
to be checked successfully. Otherwise, we would recursive infinitely.
201-
(This procedure is directly analagous to what the existing
201+
(This procedure is directly analogous to what the existing
202202
`TypeContents` code does.)
203203

204204
Note that there exist types that expand to an infinite tree of types.
@@ -367,20 +367,20 @@ traits. In effect, opt-in is anti-modular in its own way.
367367
To be more specific, imagine that library A wishes to define a
368368
`Untainted` trait, and it specifically opts out of `Untainted` for
369369
some base set of types. It then wishes to have routines that only
370-
operate on `Untained` data. Now imagine that there is some other
370+
operate on `Untainted` data. Now imagine that there is some other
371371
library B that defines a nifty replacement for `Vector`,
372372
`NiftyVector`. Finally, some library C wishes to use a
373373
`NiftyVector<uint>`, which should not be considered tainted, because
374374
it doesn't reference any tainted strings. However, `NiftyVector<uint>`
375375
does not implement `Untainted` (nor can it, without either library A
376-
or libary B knowing about one another). Similar problems arise for any
376+
or library B knowing about one another). Similar problems arise for any
377377
trait, of course, due to our coherence rules, but often they can be
378378
overcome with new types. Not so with `Send` and `Share`.
379379

380380
#### Other use cases
381381

382382
Part of the design involves making space for other use cases. I'd like
383-
to skech out how some of those use cases can be implemented briefly.
383+
to sketch out how some of those use cases can be implemented briefly.
384384
This is not included in the *Detailed design* section of the RFC
385385
because these traits generally concern other features and would be
386386
added under RFCs of their own.

text/0040-libstd-facade.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -81,7 +81,7 @@ many locations.
8181
#### Strings
8282

8383
In a post-DST world, the string type will actually be a library-defined type,
84-
`Str` (or similarly named). Strings will no longer be a lanuage feature or a
84+
`Str` (or similarly named). Strings will no longer be a language feature or a
8585
language-defined type. This implies that any methods on strings must be in the
8686
same crate that defined the `Str` type, or done through extension traits.
8787

@@ -383,7 +383,7 @@ various environments seems beneficial.
383383
etc. This route has may have the problem of "multiple standard libraries"
384384
in that code compatible with the "libc libstd" is not necessarily compatible
385385
with the "no libc libstd". Asserting that a crate is compatible with multiple
386-
profiles would involve requiring multiple compliations.
386+
profiles would involve requiring multiple compilations.
387387

388388
* Removing libstd entirely. If the standard library is simply a facade, the
389389
compiler could theoretically only inject a select number of crates into the

text/0048-traits.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -224,7 +224,7 @@ we find we need more type information to proceed with some
224224
type-overloaded operation, rather than reporting an error we can try
225225
and resolve pending constraints. If that helps give more information,
226226
we can carry on. Once we reach the end of the function, we must then
227-
resolve all pending constriants that have not yet been resolved for
227+
resolve all pending constraints that have not yet been resolved for
228228
some other reason.
229229

230230
Note that there is some interaction with the distinction between input
@@ -527,7 +527,7 @@ slightly modified example:
527527
As before, we'll start out with a type of `Monster`, but this type the
528528
method `move_to_room()` has a receiver type of `Gc<Monster>`. This
529529
doesn't match cases 1, 2, or 3, so we proceed to case 4 and *unwind*
530-
by one adustment. Since the most recent adjustment was to deref from
530+
by one adjustment. Since the most recent adjustment was to deref from
531531
`Gc<Monster>` to `Monster`, we are left with a type of
532532
`Gc<Monster>`. We now search again. This time, we match case 1. So the
533533
final result is `Mob::move_to_room(victim, room)`. This last case is
@@ -660,7 +660,7 @@ extent.
660660
## The "resolve" algorithm
661661

662662
The basis for the coherence check, method lookup, and vtable lookup
663-
algoritms is the same function, called *RESOLVE*. The basic idea is
663+
algorithms is the same function, called *RESOLVE*. The basic idea is
664664
that it takes a set of obligations and tries to resolve them. The result
665665
is four sets:
666666

text/0049-match-arm-attributes.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -9,7 +9,7 @@ Allow attributes on match arms.
99
# Motivation
1010

1111
One sometimes wishes to annotate the arms of match statements with
12-
attributes, for example with conditional complilation `#[cfg]`s or
12+
attributes, for example with conditional compilation `#[cfg]`s or
1313
with branch weights (the latter is the most important use).
1414

1515
For the conditional compilation, the work-around is duplicating the

text/0068-const-unsafe-pointers.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -104,7 +104,7 @@ the language, `const`.
104104

105105
* How much can the compiler help out when coercing `&mut T` to `*mut T`? As
106106
previously stated, the source pointer `&mut T` is consumed during the
107-
coerction (it's already a linear type), but this can lead to some unexpected
107+
coercion (it's already a linear type), but this can lead to some unexpected
108108
results:
109109

110110
extern {

text/0092-struct-grammar.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,7 @@ literals to not require the `:` (e.g., if we allow empty structs to be written
1818
with braces, or if we allow struct literals to unify field names to local
1919
variable names, as has been suggested in the past and which we currently do for
2020
struct literal patterns). We should also be able to give better error messages
21-
today if users make these mistakes. More worringly, we might come up with some
21+
today if users make these mistakes. More worryingly, we might come up with some
2222
language feature in the future which is not predictable now and which breaks
2323
with the current system.
2424

text/0100-partial-cmp.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -4,7 +4,7 @@
44

55
# Summary
66

7-
Add a `partial_cmp` method to `PartialOrd`, analagous to `cmp` in `Ord`.
7+
Add a `partial_cmp` method to `PartialOrd`, analogous to `cmp` in `Ord`.
88

99
# Motivation
1010

@@ -93,7 +93,7 @@ should be. It would also require more work to implement `PartialOrd` once the
9393
currently planned `cmp` reform has finished as noted above.
9494

9595
`partial_cmp` could just be called `cmp`, but it seems like UFCS would need to
96-
be implemented first for that to be workrable.
96+
be implemented first for that to be workable.
9797

9898
# Unresolved questions
9999

text/0109-remove-crate-id.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -72,14 +72,14 @@ Note that both the `<version>` and the `<hash>` are missing by default. The
7272
and the `<hash>` was removed to make the output filename predictable.
7373

7474
The three original goals can still be satisfied with this simplified naming
75-
scheme. As explained in th enext section, the compiler's "glob pattern" when
75+
scheme. As explained in the next section, the compiler's "glob pattern" when
7676
searching for a crate named `foo` will be `libfoo*.rlib`, which will help
7777
rationalize some of these conclusions.
7878

7979
* Libraries of the same name can exist next to one another because they can be
8080
manually renamed to have extra data after the `libfoo`, such as the version.
8181
* Libraries of the same name and version, but different source, can also exist
82-
by modifing what comes after `libfoo`, such as including a hash.
82+
by modifying what comes after `libfoo`, such as including a hash.
8383
* Rust does not need to occupy a privileged namespace as the default rust
8484
installation would include hashes in all the filenames as necessary. More on
8585
this later.
@@ -148,7 +148,7 @@ not compile a crate with two different versions of an upstream crate.
148148
Additionally, cargo could not substitute `libfast-json` for `libslow-json` at
149149
compile time (assuming they have the same API).
150150

151-
To accomodate an "expert mode" in rustc, the compiler will grow a new command
151+
To accommodate an "expert mode" in rustc, the compiler will grow a new command
152152
line flag of the form:
153153

154154
```

text/0115-rm-integer-fallback.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -51,7 +51,7 @@ enum Color { Red = 0, Green = 1, Blue = 2 }
5151
```
5252

5353
Currently, an unsuffixed integer defaults to `int`. Instead, we will
54-
only require enum descriminants primitive integers of unspecified
54+
only require enum discriminants primitive integers of unspecified
5555
type; assigning an integer to an enum will behave as if casting from
5656
from the type of the integer to an unsigned integer with the size of
5757
the enum discriminant.

text/0130-box-not-special.md

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Currently the `Box<T>` type is special-cased and converted to the old
1212
`~T` internally. This is mostly invisible to the user, but it shows up
1313
in some places that give special treatment to `Box<T>`. This RFC is
1414
specifically concerned with the fact that the borrow checker has
15-
greater precision when derefencing `Box<T>` vs other smart pointers
15+
greater precision when dereferencing `Box<T>` vs other smart pointers
1616
that rely on the `Deref` traits. Unlike the other kinds of special
1717
treatment, we do not currently have a plan for how to extend this
1818
behavior to all smart pointer types, and hence we would like to remove
@@ -103,7 +103,7 @@ treatment of box to other smart pointer types:
103103
if the optimization is not performed it affects what programs can
104104
successfully type check. (Naturally it is also observable.)
105105

106-
2. Some sort of unsafe deref trait that acknolwedges possibliity of
106+
2. Some sort of unsafe deref trait that acknowledges possibility of
107107
other pointers into the referent. Unappealing because the problem
108108
is not that bad as to require unsafety.
109109

0 commit comments

Comments
 (0)