running 396 tests
..................................................2020-11-23T12:12:37.735649Z ERROR compiletest::runtest: fatal error, panic: "failed to run tidy - is it installed? - No such file or directory (os error 2)"
F................................................. 100/396
.................................................................................................... 200/396
.................................................................................................... 300/396
...............................i...............2020-11-23T12:15:00.271271Z ERROR compiletest::runtest: fatal error, panic: "failed to run tidy - is it installed? - No such file or directory (os error 2)"
F................................................
```
------------------------------------------
stderr:
------------------------------------------
4: `@has` check failed
`XPATH PATTERN` did not match
// `@has` - '//*[`@class="rust` fn"]' 'pub fn f(callback: fn(len: usize, foo: u32))'
Encountered 1 errors
------------------------------------------
info: generating a diff against nightly rustdoc
failed to run tidy - is it installed? - Permission denied (os error 13)
failed to run tidy - is it installed? - Permission denied (os error 13)
# a diff without running `tidy`
```
running 396 tests
..................................................2020-11-23T12:12:37.735649Z ERROR compiletest::runtest: fatal error, panic: "failed to run tidy - is it installed? - No such file or directory (os error 2)"
F................................................. 100/396
.................................................................................................... 200/396
.................................................................................................... 300/396
...............................i...............2020-11-23T12:15:00.271271Z ERROR compiletest::runtest: fatal error, panic: "failed to run tidy - is it installed? - No such file or directory (os error 2)"
F................................................
```
------------------------------------------
stderr:
------------------------------------------
4: @has check failed
`XPATH PATTERN` did not match
// @has - '//*[@class="rust fn"]' 'pub fn f(callback: fn(len: usize, foo: u32))'
Encountered 1 errors
------------------------------------------
info: generating a diff against nightly rustdoc
failed to run tidy - is it installed? - Permission denied (os error 13)
failed to run tidy - is it installed? - Permission denied (os error 13)
# a diff without running `tidy`
```
bors [Sat, 12 Dec 2020 12:36:18 +0000 (12:36 +0000)]
Auto merge of #79169 - LeSeulArtichaut:ty-lib, r=nikomatsakis
Create `rustc_type_ir`
Decided to start small 😄
This PR creates a `rustc_type_ir` crate as part of the WG-Traits plan to create a shared type library.
~~There already exists a `rustc_ty` crate, so I named the new crate `rustc_ty_library`. However I think it would make sense to rename the current `rustc_ty` to something else (e.g. `rustc_ty_passes`) to free the name for this new crate.~~
Rich Kadel [Sat, 12 Dec 2020 02:28:37 +0000 (18:28 -0800)]
Fixes reported bugs in Rust Coverage
Fixes: #79569 Fixes: #79566 Fixes: #79565
For the first issue (#79569), I got hit a `debug_assert!()` before
encountering the reported error message (because I have `debug = true`
enabled in my config.toml).
The assertion showed me that some `SwitchInt`s can have more than one
target pointing to the same `BasicBlock`.
I had thought that was invalid, but since it seems to be possible, I'm
allowing this now.
I added a new test for this.
----
In the last two cases above, both tests (intentionally) fail to compile,
but the `InstrumentCoverage` pass is invoked anyway.
The MIR starts with an `Unreachable` `BasicBlock`, which I hadn't
encountered before. (I had assumed the `InstrumentCoverage` pass
would only be invoked with MIRs from successful compilations.)
I don't have test infrastructure set up to test coverage on files that
fail to compile, so I didn't add a new test.
bors [Sat, 12 Dec 2020 02:40:17 +0000 (02:40 +0000)]
Auto merge of #79931 - RalfJung:no-redundant-storage-live, r=oli-obk
make redundant StorageLive UB
The interesting behavior of StorageLive in loops (https://github.com/rust-lang/rust/issues/42371) has been fixed, so we can now finally make it a hard error to mark a local as live that is already live. :)
bors [Sat, 12 Dec 2020 00:23:29 +0000 (00:23 +0000)]
Auto merge of #79553 - sexxi-goose:mir_min_cap_writeback, r=nikomatsakis
Capture precise paths in THIR and MIR
This PR allows THIR and MIR to use the result of the new capture analysis to actually capture precise paths
To achieve we:
- Writeback min capture results to TypeckResults
- Move handling upvars to PlaceBuilder in mir_build
- Lower precise paths in THIR build by reading min_captures
- Search for ancestors in min_capture when trying to build a MIR place which starts off of an upvar
bors [Fri, 11 Dec 2020 22:00:00 +0000 (22:00 +0000)]
Auto merge of #79349 - Nemo157:issue-79201, r=jyn514
Apply `doc(cfg)` from parent items while collecting trait impls
Because trait impls bypass the standard `clean` hierarchy they do not participate in the `propagate_doc_cfg` pass, so instead we need to pre-collect all possible `doc(cfg)` attributes that will apply to them when cleaning.
bors [Fri, 11 Dec 2020 12:30:05 +0000 (12:30 +0000)]
Auto merge of #79910 - RalfJung:abort-msg, r=oli-obk
CTFE: tweak abort-on-uninhabited message
Having an "aborted execution:" makes it more consistent with the `Abort` terminator saying "the program aborted execution". Right now, at least one of the two errors will look weird in Miri.
bors [Fri, 11 Dec 2020 10:20:43 +0000 (10:20 +0000)]
Auto merge of #79915 - Aaron1011:fix/fix-reuse-def-path-hash, r=petrochenkov
Use `def_path_hash_to_def_id` when re-using a `RawDefId`
Fixes #79890
Previously, we just copied a `RawDefId` from the 'old' map to the 'new'
map. However, the `RawDefId` for a given `DefPathHash` may be different
in the current compilation session. Using `def_path_hash_to_def_id`
ensures that the `RawDefId` we use is valid in the current session.
bors [Fri, 11 Dec 2020 07:54:35 +0000 (07:54 +0000)]
Auto merge of #79893 - RalfJung:forget-windows, r=oli-obk
Windows TLS: ManuallyDrop instead of mem::forget
The Windows TLS implementation still used `mem::forget` instead of `ManuallyDrop`, leading to the usual problem of "using" the `Box` when it should not be used any more.
bors [Fri, 11 Dec 2020 05:34:07 +0000 (05:34 +0000)]
Auto merge of #79927 - tmandry:rollup-pwn4b1v, r=tmandry
Rollup of 11 pull requests
Successful merges:
- #77027 (Improve documentation for `std::{f32,f64}::mul_add`)
- #79375 (Make the kernel_copy tests more robust/concurrent.)
- #79639 (Add long explanation for E0212)
- #79698 (Add tracking issue template for library features.)
- #79809 (Dogfood `str_split_once()`)
- #79851 (Clarify the 'default is only allowed on...' error)
- #79858 (Update const-fn doc in unstable-book)
- #79860 (Clarify that String::split_at takes a byte index.)
- #79871 (Fix small typo in `wrapping_shl` documentation)
- #79896 (Make search results tab and help button focusable with keyboard)
- #79917 (Use Symbol for inline asm register class names)
Tyler Mandry [Fri, 11 Dec 2020 05:33:14 +0000 (21:33 -0800)]
Rollup merge of #79860 - rust-lang:frewsxcv-patch-2, r=jyn514
Clarify that String::split_at takes a byte index.
To someone skimming through the `String` docs and only reads the first line, the person could interpret "index" to be "char index". Later on in the docs it clarifies, but by adding "byte" it removes that ambiguity.
Tyler Mandry [Fri, 11 Dec 2020 05:33:12 +0000 (21:33 -0800)]
Rollup merge of #79858 - sasurau4:doc/update-unstable-book-const-fn, r=oli-obk
Update const-fn doc in unstable-book
Fix #79691
I couldn't find suitable examples. It seems that `const_fn` feature-gate used only following place. https://github.com/rust-lang/rust/blob/810324d1f31eb8d75e8f0044df720652986ef133/compiler/rustc_ast_passes/src/feature_gate.rs#L560-L562
And example like following emits [E0379](https://doc.rust-lang.org/error-index.html#E0379).
```rust
#![feature(const_fn)]
trait Foo {
const fn bar() -> Self;
}
```
Any other suitable example exists, please let me know.
Tyler Mandry [Fri, 11 Dec 2020 05:33:10 +0000 (21:33 -0800)]
Rollup merge of #79851 - camelid:better-error-for-default-fn, r=davidtwco
Clarify the 'default is only allowed on...' error
Code like
impl Foo {
default fn foo() {}
}
will trigger the error
error: `default` is only allowed on items in `impl` definitions
--> src/lib.rs:5:5
|
5 | default fn foo() {}
| -------^^^^^^^^^
| |
| `default` because of this
but that's very confusing! I *did* put it on an item in an impl!
So this commit changes the message to
error: `default` is only allowed on items in trait impls
--> src/lib.rs:5:5
|
5 | default fn foo() {}
| -------^^^^^^^^^
| |
| `default` because of this
Tyler Mandry [Fri, 11 Dec 2020 05:33:08 +0000 (21:33 -0800)]
Rollup merge of #79809 - Eric-Arellano:split-once, r=matklad
Dogfood `str_split_once()`
Part of https://github.com/rust-lang/rust/issues/74773.
Beyond increased clarity, this fixes some instances of a common confusion with how `splitn(2)` behaves: the first element will always be `Some()`, regardless of the delimiter, and even if the value is empty.
Given this code:
```rust
fn main() {
let val = "...";
let mut iter = val.splitn(2, '=');
println!("Input: {:?}, first: {:?}, second: {:?}", val, iter.next(), iter.next());
}
```
Tyler Mandry [Fri, 11 Dec 2020 05:33:06 +0000 (21:33 -0800)]
Rollup merge of #79698 - m-ou-se:libs-tracking-issue-template, r=KodrAus
Add tracking issue template for library features.
This adds a issue template for a library tracking issue.
There's already a template for tracking issues, but it's mostly geared towards compiler/language features. A separate template makes it a bit easier to make sure it matches with the process we use for library changes.
Main differences:
- Added a note about how small library features can be added without RFC, and removed the parts that assume there's an RFC.
- Merged the 'Steps' and 'History' sections: Library features are often small enough that there's no multiple steps planned ahead of time.
- Removed the section about avoiding large discussions and opening separate issues for problems with the feature. Library features are usually focussed enough that the discussion about a feature is best kept together in the tracking issue.
- Removed links to the rustc-dev-guide, which are specific to changes in the compiler and language.
Tyler Mandry [Fri, 11 Dec 2020 05:33:02 +0000 (21:33 -0800)]
Rollup merge of #79375 - vext01:kernel-copy-temps, r=bjorn3
Make the kernel_copy tests more robust/concurrent.
These tests write to the same filenames in /tmp and in some cases these files don't get cleaned up properly. This caused issues for us when different users run the tests on the same system, e.g.:
```
---- sys::unix::kernel_copy::tests::bench_file_to_file_copy stdout ----
thread 'sys::unix::kernel_copy::tests::bench_file_to_file_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs:71:10
---- sys::unix::kernel_copy::tests::bench_file_to_socket_copy stdout ----
thread 'sys::unix::kernel_copy::tests::bench_file_to_socket_copy' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 13, kind: PermissionDenied, message: "Permission denied" }', library/std/src/sys/unix/kernel_copy/tests.rs💯10
```
Use `std::sys_common::io__test::tmpdir()` to solve this.
bors [Fri, 11 Dec 2020 03:08:32 +0000 (03:08 +0000)]
Auto merge of #79656 - jnqnfe:ordering, r=sfackler
Add some core::cmp::Ordering helpers
...to allow easier equal-to-or-greater-than and less-than-or-equal-to
comparisons.
Prior to Rust 1.42 a greater-than-or-equal-to comparison might be written
either as a match block, or a traditional conditional check like this:
```rust
if cmp == Ordering::Equal || cmp == Ordering::Greater {
// Do something
}
```
Which requires two instances of `cmp`. Don't forget that while `cmp` here
is very short, it could be something much longer in real use cases.
From Rust 1.42 a nicer alternative is possible:
```rust
if matches!(cmp, Ordering::Equal | Ordering::Greater) {
// Do something
}
```
The commit adds another alternative which may be even better in some cases:
```rust
if cmp.is_equal_or_greater() {
// Do something
}
```
The earlier examples could be cleaner than they are if the variants of
`Ordering` are imported such that `Equal`, `Greater` and `Less` can be
referred to directly, but not everyone will want to do that.
The new solution can shorten lines, help avoid logic mistakes, and avoids
having to import `Ordering` / `Ordering::*`.
bors [Thu, 10 Dec 2020 23:43:20 +0000 (23:43 +0000)]
Auto merge of #77801 - fusion-engineering-forks:pin-mutex, r=Mark-Simulacrum
Enforce no-move rule of ReentrantMutex using Pin and fix UB in stdio
A `sys_common::ReentrantMutex` may not be moved after initializing it with `.init()`. This was not enforced, but only stated as a requirement in the comments on the unsafe functions. This change enforces this no-moving rule using `Pin`, by changing `&self` to a `Pin` in the `init()` and `lock()` functions.
This uncovered a bug I introduced in #77154: stdio.rs (the only user of ReentrantMutex) called `init()` on its ReentrantMutexes while constructing them in the intializer of `SyncOnceCell::get_or_init`, which would move them afterwards. Interestingly, the ReentrantMutex unit tests already had the same bug, so this invalid usage has been tested on all (CI-tested) platforms for a long time. Apparently this doesn't break badly on any of the major platforms, but it does break the rules.\*
To be able to keep using SyncOnceCell, this adds a `SyncOnceCell::get_or_init_pin` function, which makes it possible to work with pinned values inside a (pinned) SyncOnceCell. Whether this function should be public or not and what its exact behaviour and interface should be if it would be public is something I'd like to leave for a separate issue or PR. In this PR, this function is internal-only and marked with `pub(crate)`.
\* Note: That bug is now included in 1.48, while this patch can only make it to ~~1.49~~ 1.50. We should consider the implications of 1.48 shipping with a wrong usage of `pthread_mutex_t` / `CRITICAL_SECTION` / .. which technically invokes UB according to their specification. The risk is very low, considering the objects are not 'used' (locked) before the move, and the ReentrantMutex unit tests have verified this works fine in practice.
Edit: This has been backported and included in 1.48. And soon 1.49 too.
---
In future changes, I want to push this usage of Pin further inside `sys` instead of only `sys_common`, and apply it to all 'unmovable' objects there (`Mutex`, `Condvar`, `RwLock`). Also, while `sys_common`'s mutexes and condvars are already taken care of by #77147 and #77648, its `RwLock` should still be made movable or get pinned.
Aaron Hill [Thu, 10 Dec 2020 20:27:07 +0000 (15:27 -0500)]
Use `def_path_hash_to_def_id` when re-using a `RawDefId`
Fixes #79890
Previously, we just copied a `RawDefId` from the 'old' map to the 'new'
map. However, the `RawDefId` for a given `DefPathHash` may be different
in the current compilation session. Using `def_path_hash_to_def_id`
ensures that the `RawDefId` we use is valid in the current session.
Lyndon Brown [Thu, 10 Dec 2020 07:00:17 +0000 (07:00 +0000)]
Add some core::cmp::Ordering helpers
...to allow easier greater-than-or-equal-to and less-than-or-equal-to
comparisons, and variant checking without needing to import the enum,
similar to `Option::is_none()` / `Option::is_some()`, in situations where
you are dealing with an `Ordering` value. (Simple `PartialOrd` / `Ord`
based evaluation may not be suitable for all situations).
Prior to Rust 1.42 a greater-than-or-equal-to comparison might be written
either as a match block, or a traditional conditional check like this:
```rust
if cmp == Ordering::Equal || cmp == Ordering::Greater {
// Do something
}
```
Which requires two instances of `cmp`. Don't forget that while `cmp` here
is very short, it could be something much longer in real use cases.
From Rust 1.42 a nicer alternative is possible:
```rust
if matches!(cmp, Ordering::Equal | Ordering::Greater) {
// Do something
}
```
The commit adds another alternative which may be even better in some cases:
```rust
if cmp.is_ge() {
// Do something
}
```
The earlier examples could be cleaner than they are if the variants of
`Ordering` are imported such that `Equal`, `Greater` and `Less` can be
referred to directly, but not everyone will want to do that.
The new solution can shorten lines, help avoid logic mistakes, and avoids
having to import `Ordering` / `Ordering::*`.
bors [Thu, 10 Dec 2020 15:20:42 +0000 (15:20 +0000)]
Auto merge of #79536 - davidtwco:focal-fossa-ci, r=pietroalbini
ci: use 20.04 on x86_64-gnu-nopt builder
Switch the `x86_64-gnu-nopt` builder to use Ubuntu 20.04.
Ubuntu 20.04 has a more recent gdb version than Ubuntu 16.04 (9.1 vs 7.11.1), which is required for rust-lang/rust#77177, as 16.04's gdb 7.11.1 crashes in some cases with Split DWARF. `x86_64-gnu-nopt` is chosen because it runs compare modes, which is how Split DWARF testing is implemented in rust-lang/rust#77177.
I've not confirmed that the issue is resolved with gdb 9.1 (Feb 2020), but system was using gdb 9.2 (May 2020) and that was fine and it seems more likely to me that the bug was resolved between gdb 7.11.1 (May 2016) and gdb 9.1.
Updating a builder to use 20.04 was suggested by `@Mark-Simulacrum` in https://github.com/rust-lang/rust/pull/77117#issuecomment-731846170. I'm not sure if this is the only change that is required - if more are necessary then I'm happy to do that.
David Wood [Sun, 29 Nov 2020 15:22:36 +0000 (15:22 +0000)]
ci: use 20.04 on x86_64-gnu-nopt builder
This commit switches the x86_64-gnu-nopt builder to use Ubuntu 20.04,
which contains a more recent gdb version than Ubuntu 16.04 (newer gdb
versions fix a bug that Split DWARF can trigger, see
rust-lang/rust#77177 for motivation). x86_64-gnu-nopt is chosen because
it runs compare modes, which is how Split DWARF testing is implemented
in rust-lang/rust#77177.
bors [Thu, 10 Dec 2020 12:55:12 +0000 (12:55 +0000)]
Auto merge of #79801 - eddyb:scalar-transmute, r=nagisa
rustc_codegen_ssa: use bitcasts instead of type punning for scalar transmutes.
This specifically helps with `f32` <-> `u32` (`from_bits`, `to_bits`) in Rust-GPU (`rustc_codegen_spirv`), where (AFAIK) we don't yet have enough infrastructure to turn type punning memory accesses into SSA bitcasts.
(There may be more instances, but the one I've seen myself is `f32::signum` from `num-traits` inspecting e.g. the sign bit)
Sadly I've had to make an exception for `transmute`s between pointers and non-pointers, as LLVM disallows using `bitcast` for them.
bors [Thu, 10 Dec 2020 10:46:38 +0000 (10:46 +0000)]
Auto merge of #79621 - usbalbin:constier_maybe_uninit, r=RalfJung
Constier maybe uninit
I was playing around trying to make `[T; N]::zip()` in #79451 be `const fn`. One of the things I bumped into was `MaybeUninit::assume_init`. Is there any reason for the intrinsic `assert_inhabited<T>()` and therefore `MaybeUninit::assume_init` not being `const`?
---
I have as best as I could tried to follow the instruction in [library/core/src/intrinsics.rs](https://github.com/rust-lang/rust/blob/master/library/core/src/intrinsics.rs#L11). I have no idea what I am doing but it seems to compile after some slight changes after the copy paste. Is this anywhere near how this should be done?
Also any ideas for name of the feature gate? I guess `const_maybe_assume_init` is quite misleading since I have added some more methods. Should I add test? If so what should be tested?
Aman Arora [Thu, 26 Nov 2020 05:07:41 +0000 (00:07 -0500)]
Use precise places when lowering Closures in THIR
- Closures now use closure_min_captures to figure out captured paths
- Build upvar_mutbls using closure_min_captures
- Change logic in limit_capture_mutability to differentiate b/w
capturing parent's local variable or capturing a variable that is
captured by the parent (in case of nested closure) using PlaceBase.
Aman Arora [Thu, 26 Nov 2020 05:05:18 +0000 (00:05 -0500)]
Use Places for captures in MIR
- Use closure_min_capture maps to capture precise paths
- PlaceBuilder now searches for ancestors in min_capture list
- Add API to `Ty` to allow access to the n-th element in a
tuple in O(1) time.
bors [Thu, 10 Dec 2020 03:11:27 +0000 (03:11 +0000)]
Auto merge of #79274 - the8472:probe-eperm, r=nagisa
implement better availability probing for copy_file_range
Followup to https://github.com/rust-lang/rust/pull/75428#discussion_r469616547
Previously syscall detection was overly pessimistic. Any attempt to copy to an immutable file (EPERM) would disable copy_file_range support for the whole process.
The change tries to copy_file_range on invalid file descriptors which will never run into the immutable file case and thus we can clearly distinguish syscall availability.
bors [Thu, 10 Dec 2020 00:42:22 +0000 (00:42 +0000)]
Auto merge of #78837 - petrochenkov:keyvalexpr, r=davidtwco
Accept arbitrary expressions in key-value attributes at parse time
Continuation of https://github.com/rust-lang/rust/pull/77271.
We now support arbitrary expressions in values of key-value attributes at parse time.
```
#[my_attr = EXPR]
```
Previously only unsuffixed literals and interpolated expressions (`$expr`) were accepted.
There are two immediate motivational cases for this:
- External doc strings (`#[doc = include_str!("my_doc.md")]`, eliminating the need in https://github.com/rust-lang/rust/issues/44732) and expanding macros in this position in general. Currently such macro expansions are supported in this position in interpolated `$expr`s (the `#[doc = $doc]` idiom).
- Paths (`#[namespace = foo::bar] extern "C++" { ... }`) like proposed in https://github.com/rust-lang/rust/pull/76734.
If the attribute in question survives expansion, then the value is still restricted to unsuffixed literals by a semantic check.
This restriction doesn't prevent the use cases listed above, so this PR keeps it in place for now.
Closes https://github.com/rust-lang/rust/issues/52607.
Previous attempt - https://github.com/rust-lang/rust/pull/67121.
Some more detailed write up on internals - https://internals.rust-lang.org/t/macro-expansion-points-in-attributes/11455.
Tracking issue - https://github.com/rust-lang/rust/issues/78835.
bors [Wed, 9 Dec 2020 22:21:55 +0000 (22:21 +0000)]
Auto merge of #79867 - tmandry:rollup-7mubs3b, r=tmandry
Rollup of 12 pull requests
Successful merges:
- #79732 (minor stylistic clippy cleanups)
- #79750 (Fix trimming of lint docs)
- #79777 (Remove `first_merge` from liveness debug logs)
- #79795 (Privatize some of libcore unicode_internals)
- #79803 (Update xsv to prevent random CI failures)
- #79810 (Account for gaps in def path table during decoding)
- #79818 (Fixes to Rust coverage)
- #79824 (Strip prefix instead of replacing it with empty string)
- #79826 (Simplify visit_{foreign,trait}_item)
- #79844 (Move RWUTable to a separate module)
- #79861 (Update LLVM submodule)
- #79862 (Remove tab-lock and replace it with ctrl+up/down arrows to switch between search result tabs)
Tyler Mandry [Wed, 9 Dec 2020 21:38:36 +0000 (13:38 -0800)]
Rollup merge of #79861 - tmiasko:llvm, r=cuviper
Update LLVM submodule
* [[msan] Fix bugs when instrumenting x86.avx512*_cvt* intrinsics](https://github.com/rust-lang/llvm-project/pull/84)
* [[X86][AVX512] Only lower to VPALIGNR if we have BWI (PR48322)](https://github.com/rust-lang/llvm-project/pull/85)
Tyler Mandry [Wed, 9 Dec 2020 21:38:27 +0000 (13:38 -0800)]
Rollup merge of #79818 - richkadel:llvm-coverage-counters-2.1.0, r=tmandry
Fixes to Rust coverage
Fixes: #79725
Some macros can create a situation where `fn_sig_span` and `body_span`
map to different files.
New documentation on coverage tests incorrectly assumed multiple test
binaries could just be listed at the end of the `llvm-cov` command,
but it turns out each binary needs a `--object` prefix.
This PR fixes the bug and updates the documentation to correct that
issue. It also fixes a few other minor issues in internal implementation
comments, and adds documentation on getting coverage results for doc
tests.
Tyler Mandry [Wed, 9 Dec 2020 21:38:25 +0000 (13:38 -0800)]
Rollup merge of #79810 - Aaron1011:fix/def-path-table-gap, r=lcnr
Account for gaps in def path table during decoding
When encoding a proc-macro crate, there may be gaps in the table (since
we only encode the crate root and proc-macro items). Account for this by
checking if the entry is present, rather than using `unwrap()`
Tyler Mandry [Wed, 9 Dec 2020 21:38:12 +0000 (13:38 -0800)]
Rollup merge of #79732 - matthiaskrgr:cl12ppy, r=Dylan-DPC
minor stylistic clippy cleanups
simplify if let Some(_) = x to if x.is_some() (clippy::redundant_pattern_matching)
don't create owned values for comparison (clippy::cmp_owned)
use .contains() or .any() instead of find(x).is_some() (clippy::search_is_some)
don't wrap code block in Ok() (clipppy::unit_arg)
bors [Wed, 9 Dec 2020 19:53:23 +0000 (19:53 +0000)]
Auto merge of #77611 - oli-obk:atomic_miri_leakage, r=nagisa
Directly use raw pointers in `AtomicPtr` store/load
I was unable to find any reason for this limitation in the latest source of LLVM or in the documentation [here](http://llvm.org/docs/Atomics.html#libcalls-atomic).
bors [Wed, 9 Dec 2020 17:27:35 +0000 (17:27 +0000)]
Auto merge of #79387 - woodruffw-forks:ww/peer-cred-pid-macos, r=Amanieu
ext/ucred: Support PID in peer creds on macOS
This is a follow-up to https://github.com/rust-lang/rust/pull/75148 (RFC: https://github.com/rust-lang/rust/issues/42839).
The original PR used `getpeereid` on macOS and the BSDs, since they don't (generally) support the `SO_PEERCRED` mechanism that Linux supplies.
This PR splits the macOS/iOS implementation of `peer_cred()` from that of the BSDs, since macOS supplies the `LOCAL_PEERPID` sockopt as a source of the missing PID. It also adds a `cfg`-gated tests that ensures that platforms with support for PIDs in `UCred` have the expected data.
bors [Wed, 9 Dec 2020 13:54:07 +0000 (13:54 +0000)]
Auto merge of #79721 - Aaron1011:fix/reuse-def-path-hash, r=wesleywiser
Properly re-use def path hash in incremental mode
Fixes #79661
In incremental compilation mode, we update a `DefPathHash -> DefId`
mapping every time we create a `DepNode` for a foreign `DefId`.
This mapping is written out to the on-disk incremental cache, and is
read by the next compilation session to allow us to lazily decode
`DefId`s.
When we decode a `DepNode` from the current incremental cache, we need
to ensure that any previously-recorded `DefPathHash -> DefId` mapping
gets recorded in the new mapping that we write out. However, PR #74967
didn't do this in all cases, leading to us being unable to decode a
`DefPathHash` in certain circumstances.
This PR refactors some of the code around `DepNode` deserialization to
prevent this kind of mistake from happening again.