The intent with this chapter is to have a central place where users can
go to find out what a random bit of syntax means, be it a keyword,
symbol, or some unusual bit of composite syntax (like `for <...>`). This
should be useful both for new users (who may not know what to call this
weird `'blah` thing), and for experienced users (who may just wish to
link someone to the appropriate section on `Trait + Trait` bounds).
Where possible, entries have been linked to an appropriate section of
the book which explains the syntax. This was not possible in all cases.
If an entry is missing links, that's because I was unable to *find*
anything appropriate to link to.
This commit should include all stable keywords, operators and symbols,
as well as a selection of potentially confusing or unusual syntax.
Improving the use of 2nd and 3rd person
Adding a few contractions to make the text less formal
Tidying up some notes
Providing a little bit more clarification for Windows users
Replacing all references to the 2nd person with references to the 3rd
person (excluding `authors = [ "Your name <you@example.com>" ]` and
`file:///home/yourname/projects/hello_world` in `hello-cargo.md`)
* removed reference to struct fields from `mut` description.
* changed `..` pattern example to not be syntactically bogus.
* changed `@` pattern example for similar reasons.
(Thanks petrochenkov)
The intent with this chapter is to have a central place where users can
go to find out what a random bit of syntax means, be it a keyword,
symbol, or some unusual bit of composite syntax (like `for <...>`). This
should be useful both for new users (who may not know what to call this
weird `'blah` thing), and for experienced users (who may just wish to
link someone to the appropriate section on `Trait + Trait` bounds).
Where possible, entries have been linked to an appropriate section of
the book which explains the syntax. This was not possible in all cases.
If an entry is missing links, that's because I was unable to *find*
anything appropriate to link to.
This commit should include all stable keywords, operators and symbols,
as well as a selection of potentially confusing or unusual syntax.
This adds a chapter to the nightly section of the book on leveraging and
implementing the `#![allocator]` attribute to write custom allocators as well as
explaining the current situation with allocators.
I found these automatically, but fixed them manually to ensure the semantics are correct. I know things like these are hardly important, since they only marginally improve clarity. But at least for me typos and simple grammatical errors trigger an---unjustified---sense of unprofessionalism, despite the fact that I make them all the time and I understand that they're the sort of thing that is bound to slip through review.
Anyway, to find most of these I used:
* `ag '.*//.*(\b[A-Za-z]{2,}\b) \1\b'` for repeated words
* `ag '\b(the|this|those|these|a|it) (a|the|this|those|these|it)\b'` to find constructs like 'the this' etc. many false positives, but not too hard to scroll through them to actually find the mistakes.
* `cat ../../typos.txt | paste -d'|' - - - - - - - - - - - - - - - - - - - - - - | tr '\n' '\0' | xargs -0 -P4 -n1 ag`. Hacky way to find misspellings, but it works ok. I got `typos.txt` from [Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines)
* `ag '.*//.* a ([ae][a-z]|(o[^n])|(i[a-rt-z]))'` to find places where 'a' was followed by a vowel (requiring 'an' instead).
I also used a handful more one off regexes that are too boring to reproduce here.
This adds a chapter to the nightly section of the book on leveraging and
implementing the `#![allocator]` attribute to write custom allocators as well as
explaining the current situation with allocators.
The diff can hopefully speak for itself. Regardless: this chapter of the book contained a sentence where "the" was mistakenly repeated twice. In this same section, there was a comma separating two sentences where a period should have been. This PR fixes both issues.
This is to address issue #28803 by improving some of the references to closures, to explain what they are more clearly, while hopefully still being concise.
r? @steveklabnik
