Auto merge of #76781 - RalfJung:rollup-ve66o2j, r=RalfJung
Rollup of 10 pull requests
Successful merges:
- #76056 (Add more info for Vec Drain doc)
- #76062 (Vec slice example fix style and show type elision)
- #76262 (Use inline(never) instead of cold)
- #76335 (Make all methods of `Duration` unstably const)
- #76366 (Add Arith Tests in Library)
- #76369 (Move Various str tests in library)
- #76534 (Add doc comments for From impls)
- #76622 (Update bootstrap readme)
- #76641 (Some cleanup changes and commenting)
- #76662 (Fix liballoc test suite for Miri)
Rollup merge of #76662 - RalfJung:lib-test-miri, r=Mark-Simulacrum
Fix liballoc test suite for Miri
Mostly, fix the regression introduced by https://github.com/rust-lang/rust/pull/75207 that caused slices (i.e., references) to be created to invalid memory or memory that has aliasing pointers that we want to keep valid. @dylni this changes the type of `check_range` to only require the length, not the full reference to the slice, which indeed is all the information this function requires.
Also reduce the size of a test introduced in https://github.com/rust-lang/rust/pull/70793 to make it not take 3 minutes in Miri.
This makes https://github.com/RalfJung/miri-test-libstd work again.
Rollup merge of #76622 - jyn514:bootstrap-readme, r=Mark-Simulacrum
Update bootstrap readme
- Reflect changes in x.py defaults
- Remove recommendation to use nightly for incremental; it works fine on
beta
- Remove note that incremental chooses stage 1 by default; stage 1 is
already the default
- Update Discord -> Zulip
Rollup merge of #76335 - CDirkx:const-duration, r=ecstatic-morse
Make all methods of `Duration` unstably const
Make the following methods of `Duration` unstable const under `duration_const_2`:
- `from_secs_f64`
- `from_secs_f32`
- `mul_f64`
- `mul_f32`
- `div_f64`
- `div_f32`
This results in all methods of `Duration` being (unstable) const.
Moved the tests to `library` as part of #76268.
Possible because of #72449, which made the relevant `f32` and `f64` methods const.
Auto merge of #76771 - Dylan-DPC:rollup-qj4j3ma, r=Dylan-DPC
Rollup of 10 pull requests
Successful merges:
- #73955 (deny(unsafe_op_in_unsafe_fn) in libstd/process.rs)
- #75146 (Detect overflow in proc_macro_server subspan)
- #75304 (Note when a a move/borrow error is caused by a deref coercion)
- #75749 (Consolidate some duplicate code in the sys modules.)
- #75882 (Use translated variable for test string)
- #75886 (Test that bounds checks are elided for [..index] after .position())
- #76048 (Initial support for riscv32gc_unknown_linux_gnu)
- #76198 (Make some Ordering methods const)
- #76689 (Upgrade to pulldown-cmark 0.8.0)
- #76763 (Update cargo)
Rollup merge of #76763 - ehuss:update-cargo, r=ehuss
Update cargo
6 commits in 875e0123259b0b6299903fe4aea0a12ecde9324f..8777a6b1e8834899f51b7e09cc9b8d85b2417110
2020-09-08 20:17:21 +0000 to 2020-09-15 19:11:03 +0000
- updated yank error message (rust-lang/cargo#8697)
- Fix non-determinism with new feature resolver. (rust-lang/cargo#8701)
- Display formatted output for JSON diffing in tests. (rust-lang/cargo#8692)
- Add --name suggestion for cargo new (rust-lang/cargo#8675)
- Sweep unrelated message from unnecessary workspace infromation (rust-lang/cargo#8681)
- Docs: Make it more clear we have two types of workspaces (rust-lang/cargo#8666)
I'm not sure if the switch away from `locate` fixes any open bugs - euclio mentioned some in https://github.com/raphlinus/pulldown-cmark/issues/165, but I didn't see any related issues open for rustdoc. Let me know if I missed one.
Rollup merge of #76198 - CDirkx:const-ordering, r=dtolnay
Make some Ordering methods const
Resubmission of [PR#75463](https://github.com/rust-lang/rust/pull/75463) as per [PR#76172](https://github.com/rust-lang/rust/pull/76172).
Constify the following methods of `core::cmp::Ordering`:
- `reverse`
- `then`
Insta-stabilizes these methods as const under the `const_ordering` feature, as their implementation is a trivial match and the recent stabilization of #49146 (Allow `if` and `match` in constants).
Note: the `const_ordering` feature has never actually been used as these methods have not been `#[rustc_const_unstable]`.
Rollup merge of #75749 - ehuss:consolidate-sys, r=alexcrichton
Consolidate some duplicate code in the sys modules.
This consolidates some modules which were duplicated throughout the sys module. The intent is to make it easier to update and maintain this code. This mainly affects the wasi, sgx, and "unsupported" targets.
I explicitly skipped hermit, cloudabi, and vxworks. These tier-3 targets have copied large sections of the sys tree. I don't think they should have, but I don't want to put effort into changing them. It also doesn't help that there aren't any scripts or instructions for building them.
There are still sections of duplicate code here and there, but this PR covers the easy parts where entire modules are the same.
Rollup merge of #75304 - Aaron1011:feature/diag-deref-move-out, r=estebank
Note when a a move/borrow error is caused by a deref coercion
Fixes #73268
When a deref coercion occurs, we may end up with a move error if the
base value has been partially moved out of. However, we do not indicate
anywhere that a deref coercion is occuring, resulting in an error
message with a confusing span.
This PR adds an explicit note to move errors when a deref coercion is
involved. We mention the name of the type that the deref-coercion
resolved to, as well as the `Deref::Target` associated type being used.
Rollup merge of #75146 - tmiasko:range-overflow, r=Mark-Simulacrum
Detect overflow in proc_macro_server subspan
* Detect overflow in proc_macro_server subspan
* Add tests for overflow in Vec::drain
* Add tests for overflow in String / VecDeque operations using ranges
Auto merge of #76755 - pietroalbini:gha-macos, r=Mark-Simulacrum
Gate macOS on both Azure and GHA
As discussed in the previous infrastructure team meeting, this PR gates macOS builds on both GHA and Azure. Once this is merged we'll wait a week or two to see if there is a troublesome rate of spurious failures, and if not we'll remove the builds on the Azure side.
Auto merge of #73595 - SNCPlay42:lifetime-after-mut, r=Mark-Simulacrum
improve diagnostics for lifetime after `&mut`
If, when parsing a borrow pointee type, we see a lifetime after `mut`, suggest placing the lifetime before `mut` and eat the lifetime to avoid a large number of unhelpful diagnostics.
There are some subtleties to avoid false positives in cases like `&mut 'a + Trait`, where `&mut ('a + Trait)` is a better suggestion.
Auto merge of #73166 - jethrogb:stdarch, r=Amanieu
Update stdarch
This PR **changes the public signature** of the following functions in `core::arch::{x86, x86_64}`:
```patch
-pub unsafe fn _mm256_extract_epi8(a: __m256i, imm8: i32) -> i8
+pub unsafe fn _mm256_extract_epi8(a: __m256i, imm8: i32) -> i32
-pub unsafe fn _mm256_extract_epi16(a: __m256i, imm8: i32) -> i16
+pub unsafe fn _mm256_extract_epi16(a: __m256i, imm8: i32) -> i32
```
This change is desired so that these signatures
* are similar to those of the 128-bit versions `_mm_extract_epi8` and `_mm_extract_epi16`
* match the Intel definitions for the intrinsics
* [RFC 2325](https://github.com/rust-lang/rfcs/blob/master/text/2325-stable-simd.md) specifies that the exact vendor function signatures should be used
A [crater run](https://github.com/rust-lang/rust/pull/73166#issuecomment-667230319) revealed only a single breakage. The [vektor crate](https://github.com/AdamNiederer/vektor/blob/master/src/x86/avx2.rs#L2436-L2472) copied the incorrect signatures in `core` exactly to their own crate. The functions don't seem to be used by anyone anywhere.
Actual breakage is not expected, since due to the nature of the functions, users would generally write `_mm256_extract_epi8(...) as u8` or `_mm256_extract_epi16(...) as u16`.
See https://github.com/rust-lang/stdarch/pull/868/. Note that the changes from that stdarch PR have already partially landed in core after https://github.com/rust-lang/stdarch/pull/878/. This PR is now only about the remaining changes.
Joshua Nelson [Sat, 12 Sep 2020 02:17:16 +0000 (22:17 -0400)]
Make the default stage for x.py configurable
This allows configuring the default stage for each sub-command individually.
- Normalize the stage as early as possible, so there's no confusion
about which to use.
- Don't add an explicit `stage` option in config.toml
This offers no more flexibility than `*_stage` and makes it confusing
which takes precedence.
- Always give `--stage N` precedence over config.toml
- Fix bootstrap tests
This changes the tests to go through `Config::parse` so that they test
the actual defaults, not the dummy ones provided by `default_opts`. To
make this workable (and independent of the environment), it does not
read `config.toml` for tests.
Auto merge of #76708 - Mark-Simulacrum:lld-macos, r=alexcrichton
Always try to promote shared LLVM to the sysroot
Even when LLVM is not generally participating in a shared link with rustc, we
will likely still link to the shared dylib from rust-lld, so we still need to
promote it.
This reverts part of #76349; my expectation that the link-shared rule was sufficient was likely wrong.
Mark Rousskov [Mon, 14 Sep 2020 20:22:56 +0000 (16:22 -0400)]
Enable shared linking to LLVM on non-Windows
Windows doesn't quite support dynamic linking to LLVM yet, but on other
platforms we do. In #76708, it was discovered that we dynamically link to LLVM
from the LLVM tools (e.g., rust-lld), so we need the shared LLVM library to link
against. That means that if we do not have a shared link to LLVM, and want LLVM
tools to work, we'd be shipping two copies of LLVM on all of these platforms:
one in librustc_driver and one in libLLVM.
Also introduce an error into rustbuild if we do end up configured for shared
linking on Windows.
Auto merge of #76311 - lzutao:split_core-slice, r=lcnr
Split `core::slice` to smaller mods
Unfortunately the `#[lang = "slice"]` is too big (3003 lines), I cannot split it further.
Note for reviewer:
* I split to multiple commits for easier reviewing, but I could git squash them all to one if requested.
* Recommend pulling this change locally and using advanced git diff viewer or this command:
```
git show --reverse --color-moved=dimmed-zebra master..
```
---
I split core/slice/mod.rs to these modules:
* `ascii`: For operations on `[u8]`.
* `cmp`: For comparison operations on `[T]`, like PartialEq and SliceContains impl.
* `index`: For indexing operations like Index/IndexMut and SliceIndex.
* `iter`: For Iterator definitions and implementation on `[T]`.
- `macros`: For iterator! and forward_iterator! macros.
* `raw`: For free function to create `&[T]` or `&mut [T]` from pointer + length or a reference.
The heapsort wrapper in mod.rs is removed in favor of reexport from `sort::heapsort`.
Auto merge of #76684 - jyn514:refactor-intra-links, r=manishearth
Refactor intra doc link code
I got tired of `fold_item` being 500 lines long.
This is best reviewed one commit at a time with whitespace changes hidden.
There are no logic changes other than the last commit making a parameter checked by the caller instead of the callee.
Auto merge of #76682 - richkadel:vec-take, r=Mark-Simulacrum
Optimize behavior of vec.split_off(0) (take all)
Optimization improvement to `split_off()` so the performance meets the
intuitively expected behavior when `at == 0`, avoiding the current behavior
of copying the entire vector.
The change honors documented behavior that the original vector's
"previous capacity unchanged".
This improvement better supports the pattern for building and flushing a
buffer of elements, such as the following:
```rust
let mut vec = Vec::new();
loop {
vec.push(something);
if condition_is_met {
process(vec.split_off(0));
}
}
```
`Option` wrapping is the first alternative I thought of, but is much
less obvious and more verbose:
```rust
let mut capacity = 1;
let mut vec: Option<Vec<Stuff>> = None;
loop {
vec.get_or_insert_with(|| Vec::with_capacity(capacity)).push(something);
if condition_is_met {
capacity = vec.capacity();
process(vec.take().unwrap());
}
}
```
Directly using `mem::replace()` (instead of calling`split_off()`) could work,
but `mem::replace()` is a more advanced tool for Rust developers, and in
this case, I believe developers would assume the standard library should
be sufficient for the purpose described here.
The benefit of the approach to this change is it does not change the
existing API contract, but improves the peformance of `split_off(0)` for
`Vec`, `String` (which delegates `split_off()` to `Vec`), and any other
existing use cases.
This change adds tests to validate the behavior of `split_off()` with
regard to capacity, as originally documented, and confirm that behavior
still holds, when `at == 0`.
The change is an implementation detail, and does not require a
documentation change, but documenting the new behavior as part of its
API contract may benefit future users.
(Let me know if I should make that documentation update.)
Note, for future consideration:
I think it would be helpful to introduce an additional method to `Vec`
(if not also to `String`):
This would make it more clear how `Vec` supports the pattern, and make
it easier to find, since the behavior is similar to other `take()`
methods in the Rust standard library.
Auto merge of #75608 - estebank:suggest-boxed-match-exprs, r=lcnr,varkor
More structured suggestions for boxed trait objects instead of impl Trait on non-coerceable tail expressions
When encountering a `match` or `if` as a tail expression where the
different arms do not have the same type *and* the return type of that
`fn` is an `impl Trait`, check whether those arms can implement `Trait`
and if so, suggest using boxed trait objects.
Use structured suggestion for `impl T` to `Box<dyn T>`.
Auto merge of #75740 - GuillaumeGomez:stabilize-doc-alias-feature, r=ollie27
Stabilize doc_alias feature
Fixes #50146.
This PR intend to stabilize the `doc_alias` feature. The last remaining bits were missing checks on the attribute usage and on its arguments. Both have been added so I think we can now move to the next step.
Mark Rousskov [Sun, 6 Sep 2020 23:38:26 +0000 (19:38 -0400)]
Make bootstrap build on stable
This is generally a good idea, and will help with being able to build bootstrap
without Python over time as it means we can "just" build with cargo +beta build
rather than needing the user to set environment variables. This is a minor step,
but a necessary one on that road.
Auto merge of #76549 - ehuss:lints-comments, r=wesleywiser
Auto-generate lint documentation.
This adds a tool which will generate the lint documentation in the rustc book automatically. This is motivated by keeping the documentation up-to-date, and consistently formatted. It also ensures the examples are correct and that they actually generate the expected lint. The lint groups table is also auto-generated. See https://github.com/rust-lang/compiler-team/issues/349 for the original proposal.
An outline of how this works:
- The `declare_lint!` macro now accepts a doc comment where the documentation is written. This is inspired by how clippy works.
- A new tool `src/tools/lint-docs` scrapes the documentation and adds it to the rustc book during the build.
- It runs each example and verifies its output and embeds the output in the book.
- It does a few formatting checks.
- It verifies that every lint is documented.
- Groups are collected from `rustc -W help`.
I updated the documentation for all the missing lints. I have also added an "Explanation" section to each lint providing a reason for the lint and suggestions on how to resolve it.
This can lead towards a future enhancement of possibly showing these docs via the `--explain` flag to make them easily accessible and discoverable.
This is quite a bad hack to fix #75486. There might be a better way to check if the self type depends on generic parameters, but I wasn't able to come up with one.
Auto merge of #76123 - tmiasko:inline-args-storage, r=wesleywiser
inliner: Emit storage markers for introduced arg temporaries
When introducing argument temporaries during inlining, emit storage
marker statements just before the assignment and in the beginning of
the return block.
This ensures that such temporaries will not be considered live across
yield points after inlining inside a generator.
Auto merge of #76656 - jonas-schievink:fewer-unstable-metadata-queries, r=lcnr
Don't query stability data when `staged_api` is off
This data only needs to be encoded when `#![feature(staged_api)]` or `-Zforce-unstable-if-unmarked` is on. Running these queries takes measurable time on large crates with many items, so skip it when the unstable flags have not been enabled.
Auto merge of #76678 - jonas-schievink:rollup-vzl9yhx, r=jonas-schievink
Rollup of 12 pull requests
Successful merges:
- #75559 (unions: test move behavior of non-Copy fields)
- #76441 (Note that parallel-compiler = true causes tests to fail)
- #76527 (Remove internal and unstable MaybeUninit::UNINIT.)
- #76629 (Simplify iter zip struct doc)
- #76640 (Simplify SyncOnceCell's `take` and `drop`.)
- #76646 (Add mailmap entry)
- #76651 (Remove Windows details from Unix and VmWorks symlink() docstrings)
- #76663 (Simplify iter chain struct doc)
- #76665 (slice::from_raw_parts: explicitly mention that data must be initialized)
- #76667 (Fix CI LLVM to work on NixOS out of the box)
- #76668 (Add visualization of rustc span in doc)
- #76677 (note that test_stable_pointers does not reflect a stable guarantee)
Optimization improvement to `split_off()` so the performance meets the
intuitively expected behavior when `at == 0`, avoiding the current
behavior of copying the entire vector.
The change honors documented behavior that the method leaves the
original vector's "previous capacity unchanged".
This improvement better supports the pattern for building and flushing a
buffer of elements, such as the following:
```rust
let mut vec = Vec::new();
loop {
vec.push(something);
if condition_is_met {
process(vec.split_off(0));
}
}
```
`Option` wrapping is the first alternative I thought of, but is much
less obvious and more verbose:
```rust
let mut capacity = 1;
let mut vec: Option<Vec<Stuff>> = None;
loop {
vec.get_or_insert_with(|| Vec::with_capacity(capacity)).push(something);
if condition_is_met {
capacity = vec.capacity();
process(vec.take().unwrap());
}
}
```
Directly applying `mem::replace()` could work, but `mem::` functions are
typically a last resort, when a developer is actively seeking better
performance than the standard library provides, for example.
The benefit of the approach to this change is it does not change the
existing API contract, but improves the peformance of `split_off(0)` for
`Vec`, `String` (which delegates `split_off()` to `Vec`), and any other
existing use cases.
This change adds tests to validate the behavior of `split_off()` with
regard to capacity, as originally documented, and confirm that behavior
still holds, when `at == 0`.
The change is an implementation detail, and does not require a
documentation change, but documenting the new behavior as part of its
API contract may benefit future users.
(Let me know if I should make that documentation update.)
Note, for future consideration:
I think it would be helpful to introduce an additional method to `Vec`
(if not also to `String`):
This would make it more clear how `Vec` supports the pattern, and make
it easier to find, since the behavior is similar to other `take()`
methods in the Rust standard library.
Joshua Nelson [Sun, 13 Sep 2020 21:15:40 +0000 (17:15 -0400)]
Require `module_id` param to `resolve` to be non-empty
Previously, `resolve` would immediately check that `module_id` was
non-empty and give an error if not. This had two downsides:
- It introduced `Option`s everywhere, even if the calling function knew
it had a valid module, and
- It checked the module on each namespace, which is unnecessary: it only
needed to be checked once.
This makes the caller responsible for checking the module exists, making
the code a lot simpler.
projects / rust.git / log