Skip to content

Commit 2a2c1fd

Browse files
bugabingaSimonSapin
authored andcommitted
Minor grammar/spelling fixes (#2)
1 parent 6607982 commit 2a2c1fd

File tree

1 file changed

+5
-5
lines changed

1 file changed

+5
-5
lines changed

text/0000-liballoc.md

+5-5
Original file line numberDiff line numberDiff line change
@@ -230,10 +230,10 @@ The structure of the standard library is therefore:
230230

231231
[Tracking issue #27783] is the tracking issue for the `alloc` crate and, historically, some other crates.
232232
Although I could not find much discussion of that, I believe it has been kept unstable so far
233-
because of uncertainty of uncertainty of what is the eventual desired crate structure
234-
for the standard library, given infinite time and resources.
233+
because of uncertainty of what the eventual desired crate structure
234+
for the standard library is, given infinite time and resources.
235235

236-
In particular, could we have a single crate with some mechanism for selectively disabling
236+
In particular, should we have a single crate with some mechanism for selectively disabling
237237
or enabling some of the crate’s components, depending on which runtime dependencies
238238
are available in targeted environments?
239239
In that world, the `no_std` attribute and standard library crates other than `std`
@@ -254,8 +254,8 @@ where `std` really is the only standard library crate that exists.
254254
It may still be [desirable] to regroup the standard library into one crate,
255255
and it is probably still possible.
256256
The `core` crate could be replaced with a set of `pub use` reexport
257-
to maintained compatibility with existing users.
258-
Whatever the eventual status is for `core` is,
257+
to maintain compatibility with existing users.
258+
Whatever the eventual status for `core` is,
259259
we can do the same for `alloc`.
260260
[PR #51569] mentioned above also hopes to make this easier.
261261

0 commit comments

Comments
 (0)