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.
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!
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.
This reverts commit 9c7d5ae57c.
This was wrong... the `continue` was to ignore the latter half of the
tokens file. Another mechanism will have to be used to keep the model
grammar's tokens in sync with the actual grammar's tokens :-/
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.
The current version of the example won't compile due to unstable features.
This is an attempt to fix that, at the cost of slightly more verbose code.
Using rust 1.0.0 (a59de37e9).
It might be obvious, but I'm not well versed with rust, so feedback is very welcome.
This PR fixes two little typos in the Dining Philosophers example.
Also, there are two style points that may have been oversights but may have been deliberate, so I'll just bring them up here:
1) In the last paragraph, you say
> You’ll notice we can introduce a new binding to `table` here, and it will shadow the old one. This is often used so that you don’t need to come up with two unique names.
You already said something similar to this in the Guessing Game, but maybe you intended for this example to be independent of that one.
2) In "Rust Inside Other Languages," you introduce the idea of the "global interpreter lock" and then refer to it as the GIL a few paragraphs later without explicitly stating that GIL == global interpreter lock. It's reasonable to expect readers to make the connection, but maybe that's not what you intended.
Excellent work on the examples! Congrats on 1.0!
r? @steveklabnik
A built-in feature enabling the dereferencing of newtype structs was removed
in PR #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.
This allows compiling entire crates from memory or preprocessing source files before they are tokenized.
Minor API refactoring included, which is a [breaking-change] for libsyntax users:
* `ParseSess::{next_node_id, reserve_node_ids}` moved to rustc's `Session`
* `new_parse_sess` -> `ParseSess::new`
* `new_parse_sess_special_handler` -> `ParseSess::with_span_handler`
* `mk_span_handler` -> `SpanHandler::new`
* `default_handler` -> `Handler::new`
* `mk_handler` -> `Handler::with_emitter`
* `string_to_filemap(sess source, path)` -> `sess.codemap().new_filemap(path, source)`
Using regular pointer arithmetic to iterate collections of zero-sized types
doesn't work, because we'd get the same pointer all the time. Our
current solution is to convert the pointer to an integer, add an offset
and then convert back, but this inhibits certain optimizations.
What we should do instead is to convert the pointer to one that points
to an i8\*, and then use a LLVM GEP instructions without the inbounds
flag to perform the pointer arithmetic. This allows to generate pointers
that point outside allocated objects without causing UB (as long as you
don't dereference them), and it wraps around using two's complement,
i.e. it behaves exactly like the wrapping_* operations we're currently
using, with the added benefit of LLVM being able to better optimize the
resulting IR.
