Fixes#19759
I'm not going to bother to do more than this, as it'll end up getting re-done as part of the reference work, but at least it's correct now.
This PR is intended as alternative to #20958. It fixes the same grammar inconsistencies, but does not increase the operator precedence of `..`, leaving it at the same level as the assignment operator.
For previous discussion, see #20811 and #20958.
Grammar changes:
* allow `for _ in 1..i {}` (fixes#20241)
* allow `for _ in 1.. {}` as infinite loop
* prevent use of range notation in contexts where only operators of high precedence are expected (fixes#20811)
Parser code cleanup:
* remove `RESTRICTION_NO_DOTS`
* make `AS_PREC` const and follow naming convention
* make `min_prec` inclusive
r? nikomatsakis
Lifetime elision documentation was reference a previously existing function
that doesn't exist. After talking with Steve Klabnik, I confirmed the correct
function to be referenced and updated documentation accordingly.
Compiling won't produce an executable just yet because (as stated in the next
paragraph) there are errors. By removing this sentance, the reader won't get
confused when they expect a successful compile i.e. if they don't read ahead one
paragraph, they are going to be checking their code and wondering why it's not
compiling.
Grammar changes:
* allow 'for _ in 1..i {}' (fixes#20241)
* allow 'for _ in 1.. {}' as infinite loop
* prevent use of range notation in contexts where only operators of high
precedence are expected (fixes#20811)
Parser code cleanup:
* remove RESTRICTION_NO_DOTS
* make AS_PREC const and follow naming convention
* make min_prec inclusive
Compiling won't produce an executable just yet because (as stated in the next
paragraph) there are errors. By removing this sentance, the reader won't get
confused when they expect a successful compile i.e. if they don't read ahead one
paragraph, they are going to be checking their code and wondering why it's not
compiling.
After PR #19766 added implicit coersions `*mut T -> *const T`, the explicit casts can be removed.
(The number of such casts turned out to be relatively small).
This removes the extra "the" from the phrase "the the Rust Programming Language book", which isn't particularly grammatical, in stub documents introduced in #20802 to direct users from the old guides to the corresponding sections of the book.
There are a large number of places that incorrectly refer
to deriving in comments, instead of derives.
If someone could look at src/etc/generate-deriving-span-tests.py,
I'm not sure how those tests were passing before/if they were.
These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.
This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:
#![feature(start)] // if you're using the #[start] attribute
#![feature(main)] // if you're using the #[main] attribute
cc #20064
"Idiomatic code should not use extra whitespace in the middle of a line to provide alignment."
http://aturon.github.io/style/whitespace.html
I realize the linked page still needs an RFC, but the docs should be written in accordance with the guidelines nevertheless.
I searched for times when we were hiding functions with # in the documentation,
and fixed them to not use it unless neccesary.
I also made random improvements whenever I changed something. For example,
I changed Example to Examples, for consistency.
Fixes#13423
Replace deprecated integer suffixes. Remove integer type notations
altogether where possible. Replace uses of deprecated `range()`
function with range notation.
* Use range notation instead of deprecated `range()`
* Remove deprecated `u` integer suffixes used in ranges
* Replace deprecated `i` integer suffixes with `is` for vector numbers
`Thread::spawn()` still gives "use of unstable item" warning which I
hadn't found a way to fix.
These two attributes are used to change the entry point into a Rust program, but
for now they're being put behind feature gates until we have a chance to think
about them a little more. The #[start] attribute specifically may have its
signature changed.
This is a breaking change to due the usage of these attributes generating errors
by default now. If your crate is using these attributes, add this to your crate
root:
#![feature(start)] // if you're using the #[start] attribute
#![feature(main)] // if you're using the #[main] attribute
cc #20064
Really small correction.
This anti-example in the Closures section is supposed to fail because of a borrow, but it was failing at the type inference because of insufficient type information.
This makes it fail for the expected reason.
Just a couple of tweaks to improve the appearance of pages like [The Rust Reference](http://doc.rust-lang.org/reference.html) on mobile to advance the progress of #20850. Changing the viewport wasn't quite good enough to make it mobile-friendly, as large tables forced the page to become wider than the screen width. Using `overflow-x`, tables that are too large become horizontally scrollable instead of forcing the *entire page* to become horizontally scrollable.
Also, there was at least one case where an extremely long piece of inline code was wider than the actual width of the screen (`std::ptr::copy_nonoverlapping_memory`), so I changed `word-wrap` to allow inline code to break in the middle of words instead of only text within `pre` tags.
This isn't a change included in this PR, but rather something up for discussion. Currently, code blocks that contain long lines simply wrap onto the next line. What if rather than wrapping, they were horizontally scrollable instead? I'm not sure what the general preference is regarding this.
r? @steveklabnik
- Make punctuation/formatting consistent with the changes made to *The Rust Programming Language* in #20782.
- Use title casing for "Safety and Speed" section.
- Reword some phrases to improve clarity.
I noticed that the `deriving` keyword is deprecated and that `derive` is the replacement. This updates the reference (and other docs) to remove the use `deriving`.
Originally, this was going to be discussed and revisted, however I've been working on this for months, and a rebase on top of master was about 1 flight's worth of work so I just went ahead and did it.
This gets you as far as being able to target powerpc with, eg:
LD_LIBRARY_PATH=./x86_64-unknown-linux-gnu/stage2/lib/ x86_64-unknown-linux-gnu/stage2/bin/rustc -C linker=powerpc-linux-gnu-gcc --target powerpc-unknown-linux-gnu hello.rs
Would really love to get this out before 1.0. r? @alexcrichton
Really small correction.
This anti-example in the Closures section is supposed to fail because of a borrow, but it was failing at the type inference because of insufficient type information.
This makes it fail for the expected reason.
- Tables that are too wide for the screen scroll horizontally.
- Inline code that would force the page to become wider than the width
of the screen is broken in the middle of the word.
- Make punctuation/formatting consistent with the changes made to "The
Rust Programming Language" in #20782.
- Use title casing for "Safety and Speed" section.
- Reword some phrases to improve clarity.
uint was recently deprecated, so in following the use of i32 at first,
replace all references to uint with u32.
Also change literals from e.g. 100u to 100, so that they are no longer
usize.
`int` doesn't exist anymore. Usage of its equivalent `isize` is
discouraged since its size is platform-dependent. `i32` is used instead
in the examples. Also, integer suffixes aren't needed in the examples
anymore so we can just write `5` instead of `5i`.
Compiler gives the following warning:
`warning: the `u` suffix on integers is deprecated; use `us` or one of the fixed-sized suffixes`
And also the errror:
`error: mismatched types: expected `u64`, found `usize` (expected u64, found usize)`
Changing the suffix to `u64` results in a successful `cargo run` outputting the desired `Versions compared successfully!`
There is likely to be new users with the alpha release, and there are a lot of documents on the internet (StackOverflow, reddit, blogs) that refer to these guides, so emitting a more helpful error than "404" is nice. Hence, I've temporarily reinstated stub documents for each of the old guides, referring to as relevant a part of the book as possible.
Also, rustbook was silently ignoring some errors, which lead to an inconsistency with directory creation/file writing. This meant the CSS file was not being written if no `doc` directory existed in the users build dir (e.g. the buildbots). This should mean that the CSS will appear automatically in later builds.
Here's my PR for the changes discussed in #19823. I decided to leave `_these_` types of italics the way there were because it differentiates the use of italics for emphasis from `*key term*` italics. Otherwise, bolded terms have been changed to italics, and single and double quotes have been changed appropriately, depending on their context (my judgement may not be the best, though).
r? @steveklabnik (congratulations on #19897 being finalized and merged, by the way!)
There are hundreds of stackoverflow answers, reddit posts and blog
articles that link to these documents, so it's a nicer user experience
if they're not plain 404s.
The intention is to let these hang around only for relatively short
while. The alpha is likely to bring in many new users and they will be
reading the documents mentioned above.
This commit is an attempt to standardize the use of punctuation and
formatting in "The Rust Programming Language" as discussed in #19823.
- Convert bold text to italicized textcwhen referring to terminology.
- Convert single-quoted text to italicized or double-quoted text,
depending on context.
- Use double quotes only in the case of scare quotes or quotations.
This pulls all of our long-form documentation into a single document,
nicknamed "the book" and formally titled "The Rust Programming
Language."
A few things motivated this change:
* People knew of The Guide, but not the individual Guides. This merges
them together, helping discoverability.
* You can get all of Rust's longform documentation in one place, which
is nice.
* We now have rustbook in-tree, which can generate this kind of
documentation. While its style is basic, the general idea is much
better: a table of contents on the left-hand side.
* Rather than a almost 10,000-line guide.md, there are now smaller files
per section.
