I feel sorry for bothering you with such a literally one character changes. If it is counter productive feel free to point it out in the comments, that would be totally understandable. I could try to pack such a changes together in one PR to make them less distractive.
r? @steveklabnik
Not everyone knows this convention. We could just rename the variables in the
example, but since this notation is commonly used it's a good opportunity to
introduce it.
r? @steveklabnik
This is a minor change. Please see title. IMO this is important since this is the first instance when we talk about allocating a vector. Not saying that it is allocated on the stack here leaves room for speculation and this might put off some people (they might not even read the later sections which go into more detail about this).
The scope of these refactorings is a little bit bigger than the title implies. See each commit for details.
I’m submitting this for nitpicking now (the first 4 commits), because I feel the basic idea/implementation is sound and should work. I will eventually expand this PR to cover the translator changes necessary for all this to work (+ tests), ~~and perhaps implement a dynamic dropping scheme while I’m at it as well.~~
r? @nikomatsakis
Currently the `mipsel-unknown-linux-gnu` target doesn't actually set the
`target_arch` value to `mipsel` but it rather uses `mips`. Alternatively the
`powerpc64le` target does indeed set the `target_arch` as `powerpc64le`,
causing a bit of inconsistency between theset two.
As these are just the same instance of one instruction set, let's use
`target_endian` to switch between them and only set the `target_arch` as one
value. This should cut down on the number of `#[cfg]` annotations necessary and
all around be a little more ergonomic.
Some other shufflings as well:
* Three powerpc triples for Linux have been added recently
* An armv7 linux triple was added recently
* The 64-bit Solaris triple is now mentioned in tier 3
We are currently now also building nightlies for iOS, powerpc triples, and
armv7, but there hasn't been much vetting of the triples themselves so I've left
them in tier 3 for now.
Fixes#31334
This is just a quicker fix for this issue; since I'm working on the next draft of the book, I don't want to put a huuuge amount of work into improving it here.
Updated documentation to clarify the difference between `and_then` and `map`. This also explains why we need `and_then` in addition to `map`. Please look at the diff for more information.
r? @alexcrichton
Currently the `mipsel-unknown-linux-gnu` target doesn't actually set the
`target_arch` value to `mipsel` but it rather uses `mips`. Alternatively the
`powerpc64le` target does indeed set the `target_arch` as `powerpc64le`,
causing a bit of inconsistency between theset two.
As these are just the same instance of one instruction set, let's use
`target_endian` to switch between them and only set the `target_arch` as one
value. This should cut down on the number of `#[cfg]` annotations necessary and
all around be a little more ergonomic.
Some other shufflings as well:
* Three powerpc triples for Linux have been added recently
* An armv7 linux triple was added recently
* The 64-bit Solaris triple is now mentioned in tier 3
We are currently now also building nightlies for iOS, powerpc triples, and
armv7, but there hasn't been much vetting of the triples themselves so I've left
them in tier 3 for now.
Block comments don't have to be in the format `/*! ... !*/`
in order to be read as doc comments about the parent block.
The format `/*! ... */` is enough.
Block comments don't have to be in the format `/*! ... !*/`
in order to be read as doc comments about the parent block.
The format `/*! ... */` is enough.
