rustdoc book: talk about #![doc(test(no_crate_inject))] and #![doc(test(attr(...)))]
While investigating https://github.com/rust-lang/rust/issues/45750 i noticed that `#![doc(test(attr(...)))]` wasn't documented at all. Since this is useful for making your examples follow the same coding guidelines as your code, i wanted to add it to the Rustdoc Book. I also added `#![doc(test(no_crate_inject))]` since it's used in the same place and might be useful for macro-heavy crates. I added mentions for these to "The `doc` attribute" as well as "Documentation tests" since it's useful information in both places.
Technically the step reordering in the second commit is gated on https://github.com/rust-lang/rust/pull/45764, since before that lands attributes from the doctest come before the ones from `#![doc(test(attr(...)))]`.
MIR-borrowck: emit "`foo` does not live long enough" instead of borrow errors
Fixes#45360. As of writing, contains deduplication of existing errors.
r? @nikomatsakis
rustc_trans: atomically write .rmeta outputs to avoid races.
Fixes#45841 in a similar vein to how LLVM writes archives: write a temporary file and then rename it.
r? @alexcrichton
Simplify higher-ranked LUB/GLB
This is a better version of https://github.com/rust-lang/rust/pull/44211. It still makes higher-ranked LUB/GLB into a hard equality test, however, it does try to identify that something changed and issue a notice to the user. I wroteup https://github.com/rust-lang/rust/issues/45852 as a tracking issue for this change.
Currently, this moves straight to a hard-error, on the basis that the crater run in #44211 saw no impact. It might be good to retest -- or perhaps to try for a warning period. Trying to do the latter in a precise way would be somewhat painful, but an imprecise way might suffice -- that is, we could issue warning *whenever* a LUB/GLB operation succeeds that will later fail, even if it doesn't ultimately impact the type check. I could experiment with this.
~~I am *mildly* wary about landing this independently of other code that moves to a universe-based system. In particular, I was nervous that this change would make coherence accepts new pairs of impls that will later be errors. I have the code for the universe-based approach available, I hope to open an PR and run some tests on its impact very shortly.~~ @arielb1 points out that I was being silly.
r? @arielb1
After this change, impl Trait existentials are
desugared to a new `abstract type` definition
paired with a set of lifetimes to apply.
In-scope generics are included as parents of the
`abstract type` generics. Parent regions are
replaced with static, and parent regions
referenced in the `impl Trait` type are duplicated
at the end of the `abstract type`'s generics.
MIR: hide .rodata constants vs by-ref ABI clash in trans.
Back in #45380, constants were copied into locals during MIR creation to ensure that arguments ' memory can be used by the callee, if the constant is placed in `.rodata` and the ABI passes it by-ref.
However, there are several drawbacks (see https://github.com/rust-lang/rust/pull/45380#discussion_r150447709), most importantly the complication of constant propagation (UB if a constant ends up in `Call` arguments) and inconveniencing analyses.
Instead, I've modified the `rustc_trans` implementation of calls to copy an `Operand::Constant` argument locally if it's not immediate, and added a test that segfaults without the copy.
cc @dotdash @arielb1
incr.comp.: Implement query result cache and use it to cache type checking tables.
This is a spike implementation of caching more than LLVM IR and object files when doing incremental compilation. At the moment, only the `typeck_tables_of` query is cached but MIR and borrow-check will follow shortly. The feature is activated by running with `-Zincremental-queries` in addition to `-Zincremental`, it is not yet active by default.
r? @nikomatsakis
Short-circuiting internal iteration with Iterator::try_fold & try_rfold
These are the core methods in terms of which the other methods (`fold`, `all`, `any`, `find`, `position`, `nth`, ...) can be implemented, allowing Iterator implementors to get the full goodness of internal iteration by only overriding one method (per direction).
Based off the `Try` trait, so works with both `Result` and `Option` (🎉https://github.com/rust-lang/rust/pull/42526). The `try_fold` rustdoc examples use `Option` and the `try_rfold` ones use `Result`.
AKA continuing in the vein of PRs https://github.com/rust-lang/rust/pull/44682 & https://github.com/rust-lang/rust/pull/44856 for more of `Iterator`.
New bench following the pattern from the latter of those:
```
test iter::bench_take_while_chain_ref_sum ... bench: 1,130,843 ns/iter (+/- 25,110)
test iter::bench_take_while_chain_sum ... bench: 362,530 ns/iter (+/- 391)
```
I also ran the benches without the `fold` & `rfold` overrides to test their new default impls, with basically no change. I left them there, though, to take advantage of existing overrides and because `AlwaysOk` has some sub-optimality due to https://github.com/rust-lang/rust/issues/43278 (which 45225 should fix).
If you're wondering why there are three type parameters, see issue https://github.com/rust-lang/rust/issues/45462
Thanks for @bluss for the [original IRLO thread](https://internals.rust-lang.org/t/pre-rfc-fold-ok-is-composable-internal-iteration/4434) and the rfold PR and to @cuviper for adding so many folds, [encouraging me](https://github.com/rust-lang/rust/pull/45379#issuecomment-339424670) to make this PR, and finding a catastrophic bug in a pre-review.
fix linking error on i586
Try to fix this linking error on i586 in cross:
https://travis-ci.org/japaric/cross/builds/302095949#L8670
The problem is that `std` is built in Ubuntu 16.04 and `cross` uses a linker from 12.04.
Currently this fix solves the problem for `i686-musl` making it "supercompatible", this PR applies the fix to `i586` as well.
The cross PR is here: https://github.com/japaric/cross/pull/157
This patch makes `read_to_end` use Vec's memory-growth pattern rather
than using a custom pattern.
This has some interesting effects:
- If memory is reserved up front, `read_to_end` can be faster, as it
starts reading at the buffer size, rather than always starting at 32
bytes. This speeds up file reading by 2x in one of my use cases.
- It can reduce the number of syscalls when reading large files.
Previously, `read_to_end` would settle into a sequence of 8192-byte
reads. With this patch, the read size follows Vec's allocation
pattern. For example, on a 16MiB file, it can do 21 read syscalls
instead of 2057. In simple benchmarks of large files though, overall
speed is still dominated by the actual I/O.
- A downside is that Read implementations that don't implement
`initializer()` may see increased memory zeroing overhead.
I benchmarked this on a variety of data sizes, with and without
preallocated buffers. Most benchmarks see no difference, but reading
a small/medium file with a pre-allocated buffer is faster.
