This adds strictly more information to the source files and reduces the need for customized tooling to render the book. (While this should not change the output of _rustbook_, it is very useful when rendering the sources with external tools like Pandoc.)
This only adds the language marker to "first level" code blocks (and not to code blocks in comments inside of code examples).
r? @steveklabnik
Currently the table of contents for `rustbook` doesn't signify which page you are on.
This PR adds an 'active' class to the link for the current page, and defines the CSS rule for that class to make the link underlined and bold.
Not sure about two things:
1) Is `current_page` is a good name for the function parameter? At first I thought `current_item` would be good, but then in the `walk_item` function, you'd have `item` and `current_item`.
2) For the CSS, is both bold and underline too much? At first I had it just be underlined, but that's also how the links look when they're hovered over.
The source code snippet uses `"whatever".as_bytes()` but the compilation error message uses `b"whatever"`. Both should be consistent with each other.
r? @steveklabnik
Minor tweak: the text explaining the Borrow trait talks about slices, but the example immediately following just uses a simple reference; there are no slices involved.
r? @steveklabnik
When taking the address of an unsized field we generate a rvalue datum
for the field and then convert it to an lvalue datum. At that point,
cleanup is scheduled for the field, leading to multiple drop calls.
The problem is that we generate an rvalue datum for the field, since the
pointer does not own the data and there's already cleanup scheduled
elsewhere by the true owner. Instead, an lvalue datum must be created.
Thanks to @eddyb for identifying the underlying cause and suggesting the
correct fix.
Fixes#25549Fixes#25515
Prefer String::from over from_str; String::from_str is unstable while
String::from is stable. Promote the latter by using it in examples.
Simply migrating unstable function to the closest alternative.
Debug overflow checks for arithmetic negation landed in #24500, at which time
the `abs` method on signed integers was changed to using `wrapping_neg` to
ensure that the function never panicked. This implied that `abs` of `INT_MIN`
would return `INT_MIN`, another negative value. When this change was back-ported
to beta, however, in #24708, the `wrapping_neg` function had not yet been
backported, so the implementation was changed in #24785 to `!self + 1`. This
change had the unintended side effect of enabling debug overflow checks for the
`abs` function. Consequently, the current state of affairs is that the beta
branch checks for overflow in debug mode for `abs` and the nightly branch does
not.
This commit alters the behavior of nightly to have `abs` always check for
overflow in debug mode. This change is more consistent with the way the standard
library treats overflow as well, and it is also not a breaking change as it's
what the beta branch currently does (albeit if by accident).
cc #25378
Debug overflow checks for arithmetic negation landed in #24500, at which time
the `abs` method on signed integers was changed to using `wrapping_neg` to
ensure that the function never panicked. This implied that `abs` of `INT_MIN`
would return `INT_MIN`, another negative value. When this change was back-ported
to beta, however, in #24708, the `wrapping_neg` function had not yet been
backported, so the implementation was changed in #24785 to `!self + 1`. This
change had the unintended side effect of enabling debug overflow checks for the
`abs` function. Consequently, the current state of affairs is that the beta
branch checks for overflow in debug mode for `abs` and the nightly branch does
not.
This commit alters the behavior of nightly to have `abs` always check for
overflow in debug mode. This change is more consistent with the way the standard
library treats overflow as well, and it is also not a breaking change as it's
what the beta branch currently does (albeit if by accident).
cc #25378
* Correctly lex CRLF in string literals
* Update `extern CRATE as NAME` syntax
* Allow leading `::` in view paths
* Allow TySums in type ascriptions and impls
* Allow macros to have visibility and attributes
* Update syntax for qualified path types and expressions
* Allow block expressions to be called () and indexed []
Some modest running-time improvements to `std::collections::BitSet` on bit-sets of varying set-membership densities. This is work originally from [here](https://github.com/rayglover/alt_collections). (Benchmarks copied below)
```
std::collections::BitSet / alt_collections::BitSet
copy_dense ... 3.08x
copy_sparse ... 4.22x
count_dense ... 11.01x
count_sparse ... 8.11x
from_bytes ... 1.47x
intersect_dense ... 6.54x
intersect_sparse ... 4.37x
union_dense ... 5.53x
union_sparse ... 5.60x
```
The exception is `from_bytes`, which I've left unaltered since the optimization is rather obscure.
Compiling with the cpu feature `popcnt` gave a further ~10% improvement on my machine, but this wasn't factored in to the benchmarks above.
Similar improvements could be made to `BitVec`, although that would probably require more substantial changes.
criticism welcome!
This adds strictly more information to the source files and reduces the
need for customized tooling to render the book.
(While this should not change the output of _rustbook_, it is very
useful when rendering the sources with external tools like Pandoc.)
Hiiii soooo I'm trying to get the reference grammar and associated tests running again, and I swear I tested before but I must have had multiple things going on when I did, because the change I made in #25137 to verify.rs is totally wrong. The RustLexer.tokens file that antlr generates has two sections:
```
EQ=1
LT=2
LE=3
EQEQ=4
NE=5
...
COMMENT=56
SHEBANG=57
UTF8_BOM=58
'='=1
'<'=2
'<='=3
'=='=4
...
```
and verify.rs is only interested in the first half-- the `continue` is to ignore the second half. In 9c7d5ae, I made it panic instead. I was trying to make sure verify.rs handled everything that might happen in the first half and complain if it didn't. That would mean the reference grammar was out of sync with at least verify.rs, if not the real grammar. But it's totally ok for verify.rs to not handle the entire second half of the file.
I'm sorry for breaking this :( Good thing these tests aren't being run regularly yet...? 😳
Tiny fixes collected while reading through the Rust book. If they're too nitpicky please let me know and I'll ignore the next ones. :)
The spaces after the function and closure arguments might be intentional, but they do not make much sense: the usual formatting doesn't have such spaces, and they aren't helping align the three lines together either.
r? @steveklabnik (as suggested by [CONTRIBUTING.md](https://github.com/rust-lang/rust/blob/master/CONTRIBUTING.md))
Fixes#23968.
Since the values are stored in a u64 internally, we need to be mask away the
high bits after applying the ! operator. Otherwise, these bits will be set to
one, causing overflow.
A built-in feature enabling the dereferencing of newtype structs was removed
in PR https://github.com/rust-lang/rust/pull/11188, and this error (E0068) was added at the same time to warn of
its removal. It seems to make sense to remove the error now, given that
the obsolete feature it is warning about was removed nearly a year and a
half ago.
