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`.
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.
Make sure formatter errors are emitted by the default Write::write_fmt
Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).
Now we choose to emit an io::Error with kind Other for formatter errors.
Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].
Fixes#31879
suggest: Put the `use` in suggested code inside the quotes
Change import a trait suggestion from:
help: candidate #1: use `std::io::Write`
to
help: candidate #1: `use std::io::Write`
so that the code can be copied directly.
Fixes#31864
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.
This fixes a bug (#31845) introduced in #31105 in which lexical scopes contain items from all anonymous module ancestors, even if the path to the anonymous module includes a normal module:
```rust
fn f() {
fn g() {}
mod foo {
fn h() {
g(); // This erroneously resolves on nightly
}
}
}
```
This is a [breaking-change] on nightly but not on stable or beta.
r? @nikomatsakis
Previously, if an error was returned from the formatter that did not
originate in an underlying writer error, Write::write_fmt would return
successfully even if the formatting did not complete (was interrupted by
an `fmt::Error` return).
Now we choose to emit an io::Error with kind Other for formatter errors.
Since this may reveal error returns from `write!()` and similar that
previously passed silently, it's a kind of a [breaking-change].
