This PR adds a program which uses the JSON output from #24884 to generate a webpage with descriptions of each diagnostic error.
The page is constructed by hand, with calls to `rustdoc`'s markdown renderers where needed. I opted to generate HTML directly as I think it's more flexible than generating a markdown file and feeding it into the `rustdoc` executable. I envision adding the ability to filter errors by their properties (description, no description, used, unused), which is infeasible using the whole-file markdown approach due to the need to wrap each error in a `<div>` (markdown inside tags isn't rendered).
Architecturally, I wasn't sure how to add this generator to the distribution. For the moment I've settled on a separate Rust program in `src/etc/` that gets compiled and run by a custom makefile rule. This approach doesn't seem too hackish, but I'm unsure if my usage of makefile variables is correct, particularly the call to `rustc` (and the `LD_LIBRARY_PATH` weirdness). Other options I considered were:
* Integrate the error-index generator into `rustdoc` so that it gets invoked via a flag and can be built as part of `rustdoc`.
* Add the error-index-generator as a "tool" to the `TOOLS` array, and make use of the facilities for building tools. The main reason I didn't do this was because it seemed like I'd need to add lots of stuff. I'm happy to investigate this further if it's the preferred method.
Specifically, make count, nth, and last call the corresponding methods on the underlying iterator where possible. This way, if the underlying iterator has an optimized count, nth, or last implementations (e.g. slice::Iter), these methods will propagate these optimizations.
Additionally, change Skip::next to take advantage of a potentially optimized nth method on the underlying iterator.
This covers:
* core::iter::Chain: count, last, nth
* core::iter::Enumerate: count, nth
* core::iter::Peekable: count, last, nth
* core::iter::Skip: count, last, next (should call nth), nth
* core::iter::Take: nth
* core::iter::Fuse: count, last, nth
of #24214.
According to rust-lang/rfcs#235, `VecDeque` should have this method (`VecDeque` was called `RingBuf` at the time) but it was never implemented.
I marked this stable since "1.0.0" because it's stable in `Vec`.
Turns out that a verbatim path was leaking through to gcc via the PATH
environment variable (pointing to the bundled gcc provided by the main
distribution) which was wreaking havoc when gcc itself was run. The fix here is
to just stop passing verbatim paths down by adding more liberal uses of
`fix_windows_verbatim_for_gcc`.
Closes#25072
Turns out that a verbatim path was leaking through to gcc via the PATH
environment variable (pointing to the bundled gcc provided by the main
distribution) which was wreaking havoc when gcc itself was run. The fix here is
to just stop passing verbatim paths down by adding more liberal uses of
`fix_windows_verbatim_for_gcc`.
Closes#25072
I've added backticks in a few places to ensure correct highlighting in the HTML output (cf #25062).
Other changes include:
* Remove use of `1.` and `2.` separated by a code block as this was being rendered as two separate lists beginning at 1.
* Correct the spelling of successful in two places (from "succesful").
Other changes are a result of reflowing text to stay within the 80 character limit.
This also made me realize that I wasn't using the correct term,
'associated functions', rather than 'static methods'. So I corrected
that in the method syntax chapter.
This also made me realize that I wasn't using the correct term,
'associated functions', rather than 'static methods'. So I corrected
that in the method syntax chapter.
As pointed out in #17136 the semantics of a `BufStream` aren't always what one
expects, and it looks like other [languages like C#][c-sharp] implement a
buffered stream with only one underlying buffer. For now this commit
destabilizes the primitive in the `std::io` module to give us some more time in
figuring out what to do with it.
[c-sharp]: https://msdn.microsoft.com/en-us/library/system.io.bufferedstream%28v=vs.110%29.aspx
[breaking-change]
Specifically, make count, nth, and last call the corresponding methods
on the underlying iterator where possible. This way, if the underlying
iterator has an optimized count, nth, or last implementations (e.g.
slice::Iter), these methods will propagate these optimizations.
Additionally, change Skip::next to take advantage of a potentially
optimized nth method on the underlying iterator.
This test has deadlocked on Windows once or twice now and we've had lots of
problems in the past of threads panicking when the process is being shut down.
One of the two threads in this test is guaranteed to panic because of the
`.unwrap()` on the `send` calls, so just call `recv` on both receivers after the
test executes to ensure that both threads are dying/dead.
This did not render as intended:
>This is defined in RFC 5737 - 192.0.2.0/24 (TEST-NET-1) - 198.51.100.0/24 (TEST-NET-2) - 203.0.113.0/24 (TEST-NET-3)
vs.
> This is defined in RFC 5737
- 192.0.2.0/24 (TEST-NET-1)
- 198.51.100.0/24 (TEST-NET-2)
- 203.0.113.0/24 (TEST-NET-3)
This commit does two things: it adds an example for indexing vectors, and it changes the \"Examples\" section to use full sentences.
This change was spurred by someone in the #rust IRC channel asking if there was a `.set()` method for changing the `i`-th value of a vector (they had missed that `Vec` implements `IndexMut`, which is easy to do if you're not aware of that trait).
This script used to be used to [extract the grammar sections from the reference](https://github.com/rust-lang/rust/pull/8585), but there is [now a separate src/doc/grammar.md](https://github.com/rust-lang/rust/pull/22308) that generates grammar.html where the grammar sections that used to be in the reference live, so there is no longer a need to extract the grammar from the reference.
I ❤️ deleting code :) But I totally understand if there's a reason to keep this around that I don't know about :)
- `File::open` is for opening a file in read-only mode
- `File::create` is for opening a file in write-only mode, which is what we want instead for this example to make sense
This makes the `bit::vec::bench::bench_bit_vec_big_union` benchmark go
from `774 ns/iter (+/- 190)` to `602 ns/iter (+/- 5)`.
(There's room for more work here too: if one can guarantee 128-bit
alignment for the vector, the compiler actually optimises `union`,
`intersection` etc. to SIMD instructions, which end up being ~5x faster
that the original version, and 4x faster than the optimised version in
this patch.)
This was one last spot where directories were being leaked through with
arguments of the form `\\?\` which neither `ld.exe` nor `gcc.exe` does
understands so the prefix needed to be stripped.
Closes#25072
