Auto merge of #76790 - ssomers:btree_slice_slasher_returns, r=Mark-Simulacrum
BTreeMap: avoid slices even more
Epilogue to #73971: it seems the compiler is unable to realize that creating a slice and `get_unchecked`-ing one element is a simple fetch. So try to spell it out for the only remaining but often invoked case.
Also, the previous code doesn't seem fair game to me, using `get_unchecked` to reach beyond the end of a slice. Although the local function `slice_insert` also does that.
Auto merge of #76645 - fusion-engineering-forks:windows-lock, r=kennytm
Small cleanups in Windows Mutex.
- Move `held` into the boxed part, since the SRW lock implementation does not use this. This makes the Mutex 50% smaller.
- Use `Cell` instead of `UnsafeCell` for `held`, such that `.replace()` can be used.
- Add some comments.
- Avoid creating multiple `&mut`s to the critical section object in `ReentrantMutex`.
Auto merge of #76634 - RalfJung:miri-guaranteed-eq-ne, r=oli-obk
move guaranteed{ne,eq} implementation to compile-time machine
Currently, Miri needs a special hack to avoid using the core engine implementation of these intrinsics. That seems silly, so let's move them to the CTFE machine, which is the only machine that wants to use them.
I also added a reference to https://github.com/rust-lang/rust/issues/73722 as a warning to anyone who wants to adjust `guaranteed_eq`.
Auto merge of #76028 - aticu:improve_e0118, r=estebank,jyn514,GuillaumeGomez
Improve E0118
- Changes the "base type" terminology to "nominal type" (according to the [reference](https://doc.rust-lang.org/stable/reference/items/implementations.html#inherent-implementations)).
- Suggests removing a reference, if one is present on the type.
- Clarify what is meant by a "nominal type".
closes #69392
This is my first not-entirely-trivial PR, so please let me know if I missed anything or if something could be improved. Though I probably won't be able to fix anything in the upcoming week.
3 commits in 25391dba46262f882fa846beefaff54a966a8fa5..56a13c082ee90736c08d6abdcd90462517b703d3
2020-09-02 07:22:55 -0700 to 2020-09-14 23:20:16 -0700
- Update the description of staticlib (rust-lang-nursery/reference#884)
- Rust 1.46 now allows more features in const fn (rust-lang-nursery/reference#883)
- Document the enum changes in RFC 2195 (rust-lang-nursery/reference#879)
Rollup merge of #76759 - yoshuawuyts:fix-future-pending-ready-stabilization-label, r=Dylan-DPC
Fix stabilization marker for future_readiness_fns
Updated the rustc version in which this will be stabilized from `1.47.0 -> 1.48.0`. Fixes https://github.com/rust-lang/rust/pull/74328#issuecomment-692133125. Ref #70921.
Rollup merge of #76758 - adamlesinski:clone_clock, r=tmandry
[fuchsia] Propagate the userspace UTC clock
On Fuchsia, spawning a subprocess does not automatically
clone all of the parent process' capabilities. UTC time on
Fuchsia is managed by a top-level userspace clock capability
that is cloned and passed to subprocesses.
This change ensures that any Rust subprocess gets access to the
UTC clock, if the parent had access to it. This is critical for
tests, which on Fuchsia, use panic=abort and spawn subprocesses
per test.
Rollup merge of #76719 - hameerabbasi:min-const-generics-ty, r=lcnr
Change error message for ty param in const
This PR introduces the following changes:
* Change error message for type param in a const expression when using
`min_const_generics`
* Change `ParamInNonTrivialAnonConst` to contain an extra `bool` used for
distinguishing whether the passed-in symbol is a type or a value.
Rollup merge of #75026 - JulianKnodt:array_windows, r=Amanieu
Add array_windows fn
This mimicks the functionality added by array_chunks, and implements a const-generic form of
`windows`. It makes egregious use of `unsafe`, but by necessity because the array must be
re-interpreted as a slice of arrays, and unlike array_chunks this cannot be done by casting the
original array once, since each time the index is advanced it needs to move one element, not
`N`.
I'm planning on adding more tests, but this should be good enough as a premise for the functionality.
Notably: should there be more functions overwritten for the iterator implementation/in general?
~~I've marked the issue as #74985 as there is no corresponding exact issue for `array_windows`, but it's based of off `array_chunks`.~~
Edit: See Issue #75027 created by @lcnr for tracking issue
Auto merge of #76420 - Gelbpunkt:aarch64-linux-musl, r=pietroalbini
Add aarch64-unknown-linux-musl host builds
This adds aarch64-unknown-linux-musl to the hosts list and adds the build to the dist-arm-linux builder as `@Mark-Simulacrum` suggested to me in Zulip. `@jyn514` requested to be mentioned :smile:
I had to update the config for crosstool-ng as it had a prompt about the glibc version.
I ran `src/ci/docker/run.sh dist-arm-linux` to test it.
```
Build completed successfully in 1:31:50
Compile requests 8180
Compile requests executed 8135
Cache hits 287
Cache misses 7848
Cache timeouts 0
Cache read errors 0
Forced recaches 0
Cache write errors 0
Compilation failures 0
Cache errors 0
Non-cacheable compilations 0
Non-cacheable calls 36
Non-compilation calls 9
Unsupported compiler calls 0
Average cache write 0.000 s
Average cache read miss 6.389 s
Average cache read hit 0.000 s
Cache location Local disk: "/sccache"
Cache size 202 MiB
Max cache size 10 GiB
== clock drift check ==
local time: Sun Sep 6 19:30:17 UTC 2020
network time: Sun, 06 Sep 2020 19:30:17 GMT
== end clock drift check ==
```
Only errors were in miri due to struct fields being private (already been reported [here](https://github.com/rust-lang/rust/issues/76337))
Edit: Maybe it is helpful if I add that it is a working compiler
```sh
/rust-nightly-aarch64-unknown-linux-musl # ash install.sh
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'cargo'
install: installing component 'rls-preview'
install: installing component 'rust-analyzer-preview'
install: installing component 'clippy-preview'
install: installing component 'rustfmt-preview'
install: installing component 'llvm-tools-preview'
install: installing component 'rust-analysis-aarch64-unknown-linux-musl'
install: installing component 'rust-std-aarch64-unknown-linux-musl'
install: WARNING: failed to run ldconfig. this may happen when not installing as root. run with --verbose to see the error
Rust is ready to roll.
/ # cat test.rs
fn main() { println!("hello world"); }
/ # rustc test.rs
/ # ./test
hello world
# file test
test: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped
```
Joshua Nelson [Tue, 15 Sep 2020 04:08:37 +0000 (00:08 -0400)]
Remove unnecessary `clone()`s in bootstrap
The performance difference is negligible, but it makes me feel better.
Note that this does not remove some clones in `config`, because it would
require changing the logic around (and performance doesn't matter
for bootstrap).
Rollup merge of #76717 - ehuss:fix-rustc-book-libdir, r=Mark-Simulacrum
Fix generating rustc docs with non-default lib directory.
If `libdir` is set in `config.toml`, then the tool to generate the rustc docs was unable to run `rustc` because it could not find the shared libraries. The solution is to set the dylib search path to include the libdir.
I changed the API of `add_rustc_lib_path` to take `Command` instead of `Cargo` to try to share the code in several places. This is how it worked before https://github.com/rust-lang/rust/pull/64316, and I think this still retains the spirit of that change.
Rollup merge of #76699 - lcnr:const-infer-err, r=varkor
improve const infer error
cc #72328
reduces it from
```
error[E0282]: type annotations needed
--> src/main.rs:17:5
|
17 | Foo.bar().bar().bar().bar().baz();
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
= note: unable to infer the value of a const parameter
```
to
```
error[E0282]: type annotations needed
--> $DIR/method-chain.rs:21:33
|
LL | Foo.bar().bar().bar().bar().baz();
| ^^^
|
= note: cannot infer the value of the const parameter `N`
```
Rollup merge of #76695 - iximeow:trait-generic-bound-suggestion, r=estebank
fix syntax error in suggesting generic constraint in trait parameter
suggest `where T: Foo` for the first bound on a trait, then suggest
`, T: Foo` when the suggested bound would add to an existing set of
`where` clauses. `where T: Foo` may be the first bound if `T` has a
default, because we'd rather suggest
```
trait A<T=()> where T: Copy
```
than
```
trait A<T: Copy=()>
```
for legibility reasons.
the test case i added here is derived from [this reproduction](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2018&gist=0bf3ace9f2a183d0bdbd748c6b8e3971):
```
struct B<T: Copy> {
t: T
}
trait A<T = ()> {
fn returns_constrained_type(&self, t: T) -> B<T> {
B { t }
}
}
```
where the suggested fix,
```
trait A<T = ()>, T: Copy { ... }
```
is in fact invalid syntax!
i also found an error in the existing suggestion for `trait Base<T = String>: Super<T>` where rustc would suggest `trait Base<T = String>: Super<T>, T: Copy`, but `T: Copy` is the first of the trait's `where` clauses and should be `where T: Copy` as well. the test for that suggestion expects invalid syntax, and has been revised to a compiler-pleasing `trait Base<T = String>: Super<T> where T: Copy`.
judging by https://github.com/rust-lang/rust/pull/70009 i'll.. cc @estebank ?
Rollup merge of #76694 - wesleywiser:partitioning_cx_trait, r=davidtwco
Introduce a PartitioningCx struct
This contains all the data used by the partitioning algorithm and allows that data to be used at each stage of the partitioning. This is useful for other approaches to partitioning which may want different pieces of the data available at each step.
Rollup merge of #76669 - lzutao:core_asm, r=Amanieu
Prefer asm! over llvm_asm! in core
Replace llvm_asm! with asm! in core.
x86 asm compare (in somecases I replaced generic type with String).
* https://rust.godbolt.org/z/59eEMv
* https://rust.godbolt.org/z/v78s6q
* https://rust.godbolt.org/z/7qYY41
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.
Adam Lesinski [Tue, 15 Sep 2020 20:54:46 +0000 (13:54 -0700)]
[fuchsia] Propagate the userspace UTC clock
On Fuchsia, spawning a subprocess does not automatically
clone all of the parent process' capabilities. UTC time on
Fuchsia is managed by a top-level userspace clock capability
that is cloned and passed to subprocesses.
This change ensures that any Rust subprocess gets access to the
UTC clock, if the parent had access to it. This is critical for
tests, which on Fuchsia, use panic=abort and spawn subprocesses
per test.
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.
projects / rust.git / log