add "(see below)" to a reference to a new concept

This is because I observed someone reading the tutorial who thought they'd
missed something when they got to the mention of variable bindings.

This patch doesn't reflow the paragraphs so that you can see the semantic
change that I made, and a subsequent patch will reflow this paragraph.

Fixes https://github.com/rust-lang/rust/issues/13570.
reflow with emacs fill-paragraph (fill-column 71)
json: Fix handling of NaN/Infinity

The JSON spec requires that these special values be serialized as null; the current serialization breaks any conformant JSON parser. So encoding needs to output "null",  to_json on floating-point types can return Null as well as Number, and reading null when specifically expecting a number should be interpreted as NaN. There's no way to round-trip Infinity.
Remove unnecessary to_string calls

This commit removes superfluous to_string calls from various places
Fix a typo and a small syntactic error.

Signed-off-by: OGINO Masanori <masanori.ogino@gmail.com>
auto merge of #15194 : Sawyer47/rust/to-string-cleanup, r=alexcrichton

This commit removes superfluous to_string calls from various places
auto merge of #15192 : mrec/rust/json-nan, r=alexcrichton

The JSON spec requires that these special values be serialized as "null"; the current serialization breaks any conformant JSON parser. So encoding needs to output "null",  `to_json` on floating-point types can return `Null` as well as `Number` values, and reading a `Null` value when specifically expecting a number should be interpreted as NaN. There's no way to round-trip Infinity through JSON.

This is my first attempt at both writing Rust and opening pull requests, so please dial your derp detector up to eleven when reviewing. A `rustc --test lib.rs` in `libserialize` passes all tests; a `make check` of the whole tree fails with the error below, but it doesn't look obviously related and the docs say that `make check` is known to be flaky on Windows.

    ---- [compile-fail] compile-fail/svh-change-significant-cfg.rs stdout ----
            task '[compile-fail] compile-fail/svh-change-significant-cfg.rs' failed at 'called `Result::
    unwrap()` on an `Err` value: couldn't create file (end of file (unknown error); path=i686-pc-mingw32
    \test\compile-fail\svh-a-base.err; mode=truncate; access=write)', C:\msys\home\Mike\rust\src\libcore
    \result.rs:545

Incidentally, it may just be my lack of familiarity with the language and its idioms, but the duplication between `Encoder`/`PrettyEncoder` had a distinct code smell to it. The size of the file (~3500 lines) also made it a bit hard to navigate. Has there been any discussion of refactoring and/or breaking it up? I couldn't find anything in Issues except the ancient #9028.
auto merge of #15197 : omasanori/rust/doc-fix, r=alexcrichton
Guide: Hello, cargo
Add a note that this requires `git`.
Fix capitalization of Issue.

@chris-morgan and @huonw pointed out that even though the feature
is a proper noun, we're using it in a more generic sense here.
tha -> than

Thanks @huonw :heart:
all/some

How could I forsake `rustdoc`? :sweat_smile:

Thanks @huonw.
staticly -> statically

What's funny about this one is that spellcheck caught it, but for
some reason didn't give me the right suggestion, so I assumed that it
wasn't in my dictionary. Oh well.

Thanks @P1start! :heart:
Fix IRC linkage.

Death to `here`!

Thanks @chris-morgan :heart:
StackOverflow -> Stack Overflow

Thanks @chris-morgan
Fixing link to subreddit.

Thanks @chris-morgan :heart:
Move note about $ up

Thanks @chris-morgan :heart:
rustrt: Reorganize task usage

Most of the comments are available on the Task structure itself, but this commit
is aimed at making FFI-style usage of Rust tasks a little nicer.

Primarily, this commit enables re-use of tasks across multiple invocations. The
method `run` will no longer unconditionally destroy the task itself. Rather, the
task will be internally re-usable if the closure specified did not fail. Once a
task has failed once it is considered poisoned and it can never be used again.

Along the way I tried to document shortcomings of the current method of tearing
down a task, opening a few issues as well. For now none of the behavior is a
showstopper, but it's useful to acknowledge it. Also along the way I attempted
to remove as much `unsafe` code as possible, opting for safer abstractions.
TIL PATHEXT

Thanks @chris-morgan :heart: