Rollup of 23 pull requests #59108
Closed
Rollup of 23 pull requests #59108
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
A convenience method like fs::copy() should try to prevent pitfalls a normal user doesn't think about. In case of an empty umask, setting the file mode early prevents temporarily world readable or even writeable files, because the default mode is 0o666. In case the target is a named pipe or special device node, setting the file mode can lead to unwanted side effects, like setting permissons on `/dev/stdout` or for root setting permissions on `/dev/null`. copy_file_range() returns EINVAL, if the destination is a FIFO/pipe or a device like "/dev/null", so fallback to io::copy, too. Fixes: rust-lang#26933 Fixed: rust-lang#37885
Originally added in rust-lang#55935 to test build times, this was reverted in rust-lang#56201 due to a belief that it caused the exit code 259 spurious errors. We've since learned, however, that the 259 exit code is likely not related to this image update as we're getting it in a number of locations now. VS2017 looks like it may be required to compile LLVm in the near future, notably discovered by rust-lang#58408 where we attempted to update LLVM.
Ensure the core::ffi::VaList structure passes the improper_ctypes lint.
There's lots of comments in the code, but the main gist of this commit is that the acquisition of the global malloc lock on the `wasm32-unknown-unknown` target when threads are enabled will not spin on contention rather than block.
MIPS r6 is quite different with the previous version. It use some new target triples: mipsisa32r6-unknown-linux-gnu mipsisa32r6el-unknown-linux-gnu mipsisa64r6-unknown-linux-gnuabi64 mipsisa64r6el-unknown-linux-gnuabi64 This patch has been tested with Debian Port for mips64r6el, and the support of these triples also is included in llvm: https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
Cargo powerpc64 and powerpc64le are seeing `SIGILL` crashes in openssl, which was found to be a linking problem, fixed by newer binutils. See <rust-lang#57345 (comment)> For powerpc64 we're using crosstool-ng, which doesn't offer a newer binutils version, but we can just compile it separately. On powerpc64le we're already building binutils. Both are now updated to binutils 2.32. Closes rust-lang/cargo#6320 Closes rust-lang#57345 Closes rust-lang/rustup#1620
A `Def::Variant` should be considered as a function in mir pretty
printing. Each variant has a constructor that we must print.
Given the following enum definition:
```
pub enum TestMe {
X(usize),
}
```
We will need to generate a constructor for the variant `X` with a
signature that looks something like the following:
```
fn TestMe::X(_1: usize) -> TestMe;
```
Co-Authored-By: kennytm <kennytm@gmail.com>
…Mark-Simulacrum Prevent cache issues on version updates Fixes rust-lang#58827. cc @rust-lang/infra
…-Simulacrum appveyor: Use VS2017 for all our images Originally added in rust-lang#55935 to test build times, this was reverted in rust-lang#56201 due to a belief that it caused the exit code 259 spurious errors. We've since learned, however, that the 259 exit code is likely not related to this image update as we're getting it in a number of locations now. VS2017 looks like it may be required to compile LLVm in the near future, notably discovered by rust-lang#58408 where we attempted to update LLVM.
…oc, r=fitzgen std: Spin for a global malloc lock on wasm32 There's lots of comments in the code, but the main gist of this commit is that the acquisition of the global malloc lock on the `wasm32-unknown-unknown` target when threads are enabled will not spin on contention rather than block.
…henkov Parse lifetimes that start with a number and give specific error Fix rust-lang#58786.
Change `std::fs::copy` to use `copyfile` on MacOS and iOS `copyfile` on MacOS is similar to `CopyFileEx` on Windows. It supports copying resource forks, extended attributes, and file ACLs, none of which are copied by the current generic unix implementation. The API is available from MacOS 10.7 and iOS 4.3 (and possibly earlier but I haven't checked). Closes rust-lang#58895.
core: ensure VaList passes improper_ctypes lint Ensure the `core::ffi::VaList` structure passes the `improper_ctypes` lint. Fixes: rust-lang#58280
MIPS: add r6 support MIPS r6 is quite different with the previous version. It use some new target triples: mipsisa32r6-unknown-linux-gnu mipsisa32r6el-unknown-linux-gnu mipsisa64r6-unknown-linux-gnuabi64 mipsisa64r6el-unknown-linux-gnuabi64 This patch has been tested with Debian Port for mips64r6el, and the support of these triples also is included in llvm: https://reviews.llvm.org/rGe58c45a695f39004710b6ce940d489fee800dbd3
Default to integrated `rust-lld` linker for UEFI targets The `x86_64-unknown-uefi` target was added in rust-lang#56769 with the linker defaulting to `lld-link`. This means that a system linker with that name is required for linking. I think defaulting to `rust-lld`, which is shipped with Rust, is a better default for the following reasons: - Most systems don't have `lld-link` installed, so it forces users to install it first. - The naming of LLD executables is not standarized, so users often need to create an additional symlink before things work. For example, on Ubuntu `apt install lld` leads to an executable named `lld-link-6.0`. - We already default to `rust-lld` for [many targets](https://github.com/rust-lang/rust/search?utf8=%E2%9C%93&q=rust-lld&type=), including embedded and WASM targets, so doing the same for UEFI crates seems consistent to me. (It even seems like `x86_64-unknown-uefi` is the [only target](https://github.com/rust-lang/rust/search?q=lld-link&unscoped_q=lld-link) that uses `lld-link`.) cc @dvdhrm who added the target and @KKK669 who [proposed to use `rust-lld`](rust-lang#56769 (comment)).
Fix documentation of from_ne_bytes and from_le_bytes Copypasta mistake, the documentation of `from_ne_bytes` and `from_le_bytes` used the big-endian variant in the example snippets.
Fix ICE in MIR pretty printing
A `Def::Variant` should be considered as a function in mir pretty
printing. Each variant has a constructor that we must print.
Given the following enum definition:
```rust
pub enum TestMe {
X(usize),
}
```
We will need to generate a constructor for the variant `X` with a
signature that looks something like the following:
```
fn TestMe::X(_1: usize) -> TestMe;
```
Fixes: rust-lang#59021
…tMisdreavus Avoid some common false positives in intra doc link checking The empty string case is never going to be a link. The numeric case may be a link, but if it were it would have resolved locally. It's more likely the makeshift markdown footnote notation (`[0]`, etc) r? @QuietMisdreavus
Track embedded-book in the toolstate The embedded book was tested in the tools job but the test result was never published. This PR adds maintainer information of embedded-book. This PR also requires the next update to embedded-book to pass the all tests, currently its state is test-fail. rust-lang-nursery/rust-toolstate#10 should be merged before this PR.
…ackler
Use lifetime contravariance to elide more lifetimes in core+alloc+std
Sample:
```diff
- impl<'a, 'b, A: ?Sized, B: ?Sized> PartialEq<&'b mut B> for &'a mut A where A: PartialEq<B> {
+ impl<A: ?Sized, B: ?Sized> PartialEq<&mut B> for &mut A where A: PartialEq<B> {
#[inline]
- fn eq(&self, other: &&'b mut B) -> bool { PartialEq::eq(*self, *other) }
+ fn eq(&self, other: &&mut B) -> bool { PartialEq::eq(*self, *other) }
#[inline]
- fn ne(&self, other: &&'b mut B) -> bool { PartialEq::ne(*self, *other) }
+ fn ne(&self, other: &&mut B) -> bool { PartialEq::ne(*self, *other) }
}
```
[I didn't know this worked](https://internals.rust-lang.org/t/why-can-you-use-different-unconstrained-lifetimes-to-implement-traits/9544/2?u=scottmcm) until recently, but since defining methods contravariantly in their lifetimes this way has worked back to Rust 1.0, we might as well take advantage of combining it with IHLE.
we can now skip should_panic tests with the libtest harness
add suggestions to invalid macro item error r? @estebank
…frewsxcv Fix incorrect links in librustc_codegen_llvm documentation
…Centril A few improvements to comments in user-facing crates Not too many this time, and all concern comments (almost all doc comments) in user-facing crates (libstd, libcore, liballoc). r? @steveklabnik
Remove precompute_in_scope_traits_hashes r? @michaelwoerister
…=oli-obk Reduces Code Repetitions like `!n >> amt` Fixes rust-lang#49937 . This PR contains defining a function which operates bit inversion and reducing bit operation like `!0u128 >> (128 - size.bits())`.
[CI] Update binutils for powerpc64 and powerpc64le Cargo powerpc64 and powerpc64le are seeing `SIGILL` crashes in openssl, which was found to be a linking problem, fixed by newer binutils. See <rust-lang#57345 (comment)> For powerpc64 we're using crosstool-ng, which doesn't offer a newer binutils version, but we can just compile it separately. On powerpc64le we're already building binutils. Both are now updated to binutils 2.32. Closes rust-lang/cargo#6320 Closes rust-lang#57345 Closes rust-lang/rustup#1620
|
@bors r+ p=23 |
|
📌 Commit 98ba2fb has been approved by |
bors
added
the
S-waiting-on-bors
|
(Please retry if 3-hour timeout.) |
bors
added
S-waiting-on-author
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
std::fs::copyto usecopyfileon MacOS and iOS #58901 (Changestd::fs::copyto usecopyfileon MacOS and iOS)rust-lldlinker for UEFI targets #58976 (Default to integratedrust-lldlinker for UEFI targets)!n >> amt#59101 (Reduces Code Repetitions like!n >> amt)