Mini doc rollup #23387
Merged
Mini doc rollup #23387
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
LLVM_LIBDIR_<triple> is only defined for host triples, not target triples. FWIW, the same is true for LLVM_STDCPP_RUSTFLAGS_<triple>, where we explicitly define it as empty when --enable-llvm-static-stdcpp is not specified, but it's still undefined for cross-compiled triples.
It wasn't clear to me that early_error was correct here, but it seems to
work. This code is reachable from `rustdoc`, which is problematic, because
early_error panics. rustc handles the panics gracefully (without ICEing or
crashing), but rustdoc does not. It's not the first such rustdoc problem,
though:
$ rustdoc hello.rs --extern std=bad-std
error: extern location for std does not exist: bad-std
hello.rs:1:1: 1:1 error: can't find crate for `std`
hello.rs:1
^
error: aborting due to 2 previous errors
thread '<unnamed>' panicked at 'Box<Any>', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libsyntax/diagnostic.rs:151
thread '<unnamed>' panicked at 'called `Result::unwrap()` on an `Err` value: "rustc failed"', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libcore/result.rs:744
thread '<main>' panicked at 'child thread None panicked', /home/rustbuild/src/rust-buildbot/slave/nightly-dist-rustc-linux/build/src/libstd/thread.rs:661
LLVM older that 3.6 has a bug that cause assertions when compiling certain constructs. For 3.5 there's still a chance that the bug might get fixed in 3.5.2, so let's keep allowing to compile with it for it for now.
In case that there is a destination for the array, like in "let x = [expr; n]", we currently don't evaluate the given expression if n is zero. That's inconsistent with all other cases, including "[expr; 0]" without a destination. Fixes rust-lang#23354
Now that `old_io` is deprecated and `std::io` is stable, we should stop recommending the use of `old_io` in the module documentation.
std::io does not currently expose the stdin_raw, stdout_raw, or stderr_raw functions. According to the current plans for stdio (see RFC rust-lang#517), raw access will likely be provided using the platform-specific std::os::{unix,windows} modules. At the moment we don't expose any way to do this. As such, delete all mention of the _raw functions from the stdin/stdout/stderr function documentation. While we're at it, remove a few `pub`s from items that aren't exposed. This is done just to lessen the confusion experienced by anyone who looks at the source in an attempt to find the _raw functions.
Previously it would fail on a trivial case like
/// Summary line
/// <trailing space>
/// Regular content
Compliant markdown preprocessor would render that as two separate paragraphs, but our summary line
extractor interprets both lines as the same paragraph and includes both into the short summary resulting in
non_camel_case_types lint suggests `ONETWOTHREE` for non-camel type `ONE_TWO_THREE`, which doesn't look good. This patch fixes it.
…chton This change closes rust-lang#23303 by rejecting an empty search path.
LLVM older that 3.6 has a bug that cause assertions when compiling certain constructs. For 3.5 there's still a chance that the bug might get fixed in 3.5.2, so let's keep allowing to compile with it for it for now.
There was a minor typo in the book's concurrency section (\"recieve\" instead of \"receive\").
[expr; 0] currently exhibits inconsistent behaviour and [expr; n] with n > 1 triggers an LLVM assertion in case that \"expr\" diverges.
…book, r=steveklabnik It was using tabs.
…r, r=steveklabnik "body": null,
…on-from-io, r=huonw Now that `old_io` is deprecated and `std::io` is stable, we should stop recommending the use of `old_io` in the module documentation.
…nstructors, r=alexcrichton `std::io` does not currently expose the `stdin_raw`, `stdout_raw`, or `stderr_raw` functions. According to the current plans for stdio (see rust-lang/rfcs#517), raw access will likely be provided using the platform-specific `std::os::{unix,windows}` modules. At the moment we don't expose any way to do this. As such, delete all mention of the `*_raw` functions from the `stdin`/`stdout`/`stderr` function documentation. While we're at it, remove a few `pub`s from items that aren't exposed. This is done just to lessen the confusion experienced by anyone who looks at the source in an attempt to find the `*_raw` functions.
This changed `an String` to `a String`. Very minor change! The usage of `an String` was introduced in rust-lang@a828e79#diff-b596503c7c33ce457b6d047e351ac12bR423, which changed `an OsString` to `an String`.
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
@bors: r+ |
|
(Given that the queue is pretty empty and it's the weekend, let's not waste build time individually testing these PRs) |
|
@bors: p=1 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
an Stringin env.rs documentation #23384