Refinement of paragraph referenced by [this issue](https://github.com/rust-lang/rust/issues/31927).
The paragraph in question had been adjusted already, but I've made some further clarifications which should help with readability and not leave the reader any `dangling pointers`.
In particular, uses of inclusive ranges within the standard library are
still waiting. Slices and collections can be sliced with `usize` and
`Range*<usize>`, but not yet `Range*Inclusive<usize>`.
Also, we need to figure out what to do about `RangeArgument`. Currently
it has `start()` and `end()` methods which are pretty much identical to
`Range::start` and `Range::end`. For the same reason as Range itself,
these methods can't express a range such as `0...255u8` without
overflow. The easiest choice, it seems to me, is either changing the
meaning of `end()` to be inclusive, or adding a new method, say
`last()`, that is inclusive and specifying that `end()` returns `None`
in cases where it would overflow. Changing the semantics would be a
breaking change, but `RangeArgument` is unstable so maybe we should do
it anyway.
Since the desugaring removed special handling for ranges, the error
message changed and so I had to adjust `range-1`.
Turns out there was a bug where borrowck was too restrictive in some
rare cases of constructing ranges from literals. The `range-2` test
enshrined this bug -- now it's adjusted to test a case that's actually
wrong.
Mostly copy the tests from half-open ranges, adding some more for
DoubleEndedIterator and ExactSizeIterator.
Also thoroughly (I think) test that the feature gates are working.
The range desugaring does not use the lang items. Hence I did not add
lang items for inclusive ranges. This cleanup commit removes the old
unused ones as well.
Whether the desugaring _should_ use lang items is another question:
see #30809. But if we decide on a strategy there we can add back these
lang items, and new ones for inclusive ranges.
For stage0 we need to keep the attributes as the lang items still exist
even if they are never used.
This is surprisingly not a breaking change. Unused #[lang] attributes do
not even trigger a lint (see #30881).
A whole bunch of stuff gets folded into struct handling! Plus, removes
an ugly hack from trans and accidentally fixes a bug with constructing
ranges from references (see later commits with tests).
These `_post` methods are quite helpful to control lint behavior without storing e.g. block node ids. So here are a few more I believe will be helpful.
r? @Manishearth
For summary descriptions we need the first paragraph (adjacent lines
until a blank line) - but the rendered markdown of a code block did not
leave a blank line in the html and was thus included in the summary line.
Hello.
I've added links for items inside of some stable methods for consistency with existing ones that already have them. Also includes minor formatting fixes.
r? @steveklabnik
When foldings Substs, we map over VecPerParamSpace instances using
EnumeratedItems which does not provide an accurate size_hint()
in its Iterator implementation. This leads to quite a large number or
reallocations. Providing a suitable size_hint() implementation reduces
the time spent in item-bodies checking quite a bit.
```
crate | before | after | ~change
-------|-------------------------
core | 7.28s | 5.44s | -25%
std | 2.07s | 1.88s | -9.2%
syntax | 8.86s | 8.30s | -6.3%
```
These `_post` methods are quite helpful to control lint behavior without storing e.g. block node ids. So here are a few more I believe will be helpful.
r? @Manishearth
Use .copy_from_slice() where applicable
.copy_from_slice() does the same job of .clone_from_slice(), but the
former is explicitly for Copy elements and calls `memcpy` directly, and
thus is it efficient without optimization too.
When foldings Substs, we map over VecPerParamSpace instances using
EnumeratedItems which does not provide an accurate size_hint()
in its Iterator implementation. This leads to quite a large number or
reallocations. Providing a suitable size_hint() implementation reduces
the time spent in item-bodies checking quite a bit.
```
crate | before | after | ~change
-------|-------------------------
core | 7.28s | 5.44s | -25%
std | 2.07s | 1.88s | -9.2%
syntax | 8.86s | 8.30s | -6.3%
```
CryptGenRandom takes a DWORD (u32) for the length so it only supports
writing u32::MAX bytes at a time.
Casting the length from a usize caused truncation meaning the whole
buffer was not always filled.
cc #31841
This is the same as rust-lang-nursery/rand#99. I think it's a good idea to keep the implementations in sync.
r? @alexcrichton
Similar to #31825 where the read/write limits were capped for files, this
implements similar limits when reading/writing networking types. On Unix this
shouldn't affect anything because the write size is already a `usize`, but on
Windows this will cap the read/write amounts to `i32::max_value`.
cc #31841
.copy_from_slice() does the same job of .clone_from_slice(), but the
former is explicitly for Copy elements and calls `memcpy` directly, and
thus is it efficient without optimization too.
The `--disable-jemalloc` configure option has a failure mode where it will
create a distribution that is not compatible with other compilers. For example
the nightly for Linux will assume that it will link to jemalloc by default as
an allocator for executable crates. If, however, a standard library is used
which was built via `./configure --disable-jemalloc` then this will fail
because the jemalloc crate wasn't built.
While this seems somewhat reasonable as a niche situation, the same mechanism is
used for disabling jemalloc for platforms that just don't support it. For
example if the rumprun target is compiled then the sibiling Linux target *also*
doesn't have jemalloc. This is currently a problem for our cross-build nightlies
which build many targets. If rumprun is also built, it will disable jemalloc for
all targets, which isn't desired.
This commit moves the platform-specific disabling of jemalloc as hardcoded logic
into the makefiles that is scoped per-platform. This way when configuring
multiple targets **without the `--disable-jemalloc` option specified** all
targets will get jemalloc as they should.
