The intent with this chapter is to have a central place where users can
go to find out what a random bit of syntax means, be it a keyword,
symbol, or some unusual bit of composite syntax (like `for <...>`). This
should be useful both for new users (who may not know what to call this
weird `'blah` thing), and for experienced users (who may just wish to
link someone to the appropriate section on `Trait + Trait` bounds).
Where possible, entries have been linked to an appropriate section of
the book which explains the syntax. This was not possible in all cases.
If an entry is missing links, that's because I was unable to *find*
anything appropriate to link to.
This commit should include all stable keywords, operators and symbols,
as well as a selection of potentially confusing or unusual syntax.
Major revision to the dropck_legal_cycles test.
1. Added big comment block explaining the test framework.
2. Added tests exericising Rc and Arc. This was inspired by a comment
from eefriedman on PR #28861.
3. Made the cycle-detection not issue false-positives on acyclic dags.
Doing this efficiently required revising the framework; instead of
visiting all children (i.e. doing a traversal), now each test is
responsible for supplying the path that will act as a witness to
the cycle.
Luckily for me, all of the pre-existing tests worked with a trivial
path built from "always tke your first left", but new tests I added
did require other input paths (i.e., "first turn right, then left".
(The path representation is a bit-string and its branches are
n-ary, not word phrases and binary branches as you might think
from the outline above.)
cc PR #27185
1. Added big comment block explaining the test framework.
2. Added tests exericising Rc and Arc. This was inspired by a comment
from eefriedman on PR #28861.
3. Made the cycle-detection not issue false-positives on acyclic dags.
Doing this efficiently required revising the framework; instead of
visiting all children (i.e. doing a traversal), now each test is
responsible for supplying the path that will act as a witness to
the cycle.
Luckily for me, all of the pre-existing tests worked with a trivial
path built from "always tke your first left", but new tests I added
did require other input paths (i.e., "first turn right, then left".
(The path representation is a bit-string and its branches are
n-ary, not word phrases and binary branches as you might think
from the outline above.)
* removed reference to struct fields from `mut` description.
* changed `..` pattern example to not be syntactically bogus.
* changed `@` pattern example for similar reasons.
(Thanks petrochenkov)
The intent with this chapter is to have a central place where users can
go to find out what a random bit of syntax means, be it a keyword,
symbol, or some unusual bit of composite syntax (like `for <...>`). This
should be useful both for new users (who may not know what to call this
weird `'blah` thing), and for experienced users (who may just wish to
link someone to the appropriate section on `Trait + Trait` bounds).
Where possible, entries have been linked to an appropriate section of
the book which explains the syntax. This was not possible in all cases.
If an entry is missing links, that's because I was unable to *find*
anything appropriate to link to.
This commit should include all stable keywords, operators and symbols,
as well as a selection of potentially confusing or unusual syntax.
This adds a chapter to the nightly section of the book on leveraging and
implementing the `#![allocator]` attribute to write custom allocators as well as
explaining the current situation with allocators.
I found these automatically, but fixed them manually to ensure the semantics are correct. I know things like these are hardly important, since they only marginally improve clarity. But at least for me typos and simple grammatical errors trigger an---unjustified---sense of unprofessionalism, despite the fact that I make them all the time and I understand that they're the sort of thing that is bound to slip through review.
Anyway, to find most of these I used:
* `ag '.*//.*(\b[A-Za-z]{2,}\b) \1\b'` for repeated words
* `ag '\b(the|this|those|these|a|it) (a|the|this|those|these|it)\b'` to find constructs like 'the this' etc. many false positives, but not too hard to scroll through them to actually find the mistakes.
* `cat ../../typos.txt | paste -d'|' - - - - - - - - - - - - - - - - - - - - - - | tr '\n' '\0' | xargs -0 -P4 -n1 ag`. Hacky way to find misspellings, but it works ok. I got `typos.txt` from [Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines)
* `ag '.*//.* a ([ae][a-z]|(o[^n])|(i[a-rt-z]))'` to find places where 'a' was followed by a vowel (requiring 'an' instead).
I also used a handful more one off regexes that are too boring to reproduce here.
This is a revival of #23364. Github didn’t recognize my updated branch there.
The cursor implementation now uses `AsRef` which means that fixed-sized array can now be used with `Cursor`. Besides that, the generic implementation simplifies the code as the macro can be avoided.
The only drawback is, that specialized implementation for fixed-sized arrays are now ruled out unless [RFC#1210](https://github.com/rust-lang/rfcs/pull/1210) is accepted & implemented.
`Box<[u8]>` cannot be used yet, but that should be mitigated by [implementing `AsRef` for `Box` and friends](https://internals.rust-lang.org/t/forward-implement-traits-on-smart-pointers-make-smart-pointers-more-transparent/2380/3). I will submit a separate PR for that later as it is an orthogonal issue.
This adds a chapter to the nightly section of the book on leveraging and
implementing the `#![allocator]` attribute to write custom allocators as well as
explaining the current situation with allocators.
Currently the explain command line flag requires full error codes, complete with
the leading zeros and the E at the beginning. This commit changes that,
if you don't supply a full error code then the error number is padded
out to the required size and the E is added to the beginning.
This means that where previously you would need to write E0001, you can
now write 0001, 001, 01 or just 1 to refer to the same error.
This new version takes inspiration from the C implementation of the benchmark, but instead of explicitly using SIMD operations which can't be done on stable, it instead arranges everything the same way and leaves the actual vectorization up to LLVM.
In addition to the ~20% speed gains (see below), this PR also adds some general niceties which showcase the language a little bit: a `Vec3` type to cut down on `(x, y, z)` repetition, using `while let` instead of `loop-if-break`, iterator adapters instead of for loops etc.
Here are the times in seconds of 10 runs each on my workstation:
```
before: 6.254, 6.260, 6.263, 6.264, 6.265, 6.267, 6.334, 6.341, 6.441, 6.509
before-min: 6.254
before-median: 6.266
before-max: 6.509
after: 4.823, 4.824, 4.826, 4.827, 4.837, 4.839, 4.881, 4.959, 4.990, 5.377
after-min: 4.823
after-median: 4.838
after-max: 5.377
gcc: 4.674, 4.676, 4.680, 4.682, 4.695, 4.696, 4.701, 4.708, 4.794, 5.297
gcc-min: 4.674
gcc-median: 4.696
gcc-max: 5.297
```
On my i7 laptop the speed up is less impressive, from ~5.4s to ~4.7s, but still significant. On my Vultr VPS the numbers look closer to the workstation results. Surprisingly my laptop beats both office workstation and VPS...
It's not very common to store `Wrapping` values, but I kept wrapping and unwrapping a hash value when I taking it out of a struct to do operations on it. I couldn't store the hash as `Wrapping<u64>` because I wanted to be able to `#[derive(Default)]` for the struct.
At any rate, it feels to me that `Wrapping<T>` should implement pretty much everything `T` does. I left out `#[derive(Hash)]` since I'd be hard pressed to find a use case and wanted to avoid the extra generated code, but maybe I should add that too?
