bors [Sun, 13 Dec 2020 08:40:07 +0000 (08:40 +0000)]
Auto merge of #79956 - camelid:variant-field-vis, r=petrochenkov
Resolve enum field visibility correctly
Fixes #79593. :tada:
Previously, this code treated enum fields' visibility as if they were
struct fields. However, that's not correct because the visibility of a
struct field with `ast::VisibilityKind::Inherited` is private to the
module it's defined in, whereas the visibility of an *enum* field with
`ast::VisibilityKind::Inherited` is the visibility of the enum it
belongs to.
In HTML, when a button follows an input (in a `form`), if the enter keep is pressed on the input, instead of sending the submit event to the input, it'll create a click event on the button following it, which in this case made the help popup show up whenever "enter" was pressed.
Yuki Okushi [Sun, 13 Dec 2020 02:05:47 +0000 (11:05 +0900)]
Rollup merge of #79984 - Nadrieril:remove-unused-dep, r=jyn514
Remove an unused dependency that made `rustdoc` crash
Whilst struggling with https://github.com/rust-lang/rust/issues/79980 I discovered that this dependency was unused, and that made rustdoc crash. This PR removes it.
Yuki Okushi [Sun, 13 Dec 2020 02:05:45 +0000 (11:05 +0900)]
Rollup merge of #79973 - camelid:rustdoc-search-tab-color, r=GuillaumeGomez
rustdoc light theme: Fix CSS for selected buttons
Fixes #79961.
The background was dark before, which made the text impossible to read.
Now the button doesn't override the background, and the only thing it
does is add a light-blue top border.
Ultimately, the search results tabs now look very similar to how they
used to look.
Yuki Okushi [Sun, 13 Dec 2020 02:05:40 +0000 (11:05 +0900)]
Rollup merge of #79954 - jyn514:normalize-oops, r=Mark-Simulacrum
Fix building compiler docs with stage 0
This regressed in https://github.com/rust-lang/rust/pull/79525 (see https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/Can't.20document.20single.20crate).
Yuki Okushi [Sun, 13 Dec 2020 02:05:36 +0000 (11:05 +0900)]
Rollup merge of #79940 - matthiaskrgr:cl15ppy, r=Dylan-DPC
fix more clippy::complexity findings
fix clippy::unnecessary_filter_map
use if let Some(x) = .. instead of ...map(|x|) to conditionally run fns that return () (clippy::option_map_unit_fn)
fix clippy::{needless_bool, manual_unwrap_or}
don't clone types that are copy (clippy::clone_on_copy)
don't convert types into identical types with .into() (clippy::useless_conversion)
use strip_prefix over slicing (clippy::manual_strip)
Yuki Okushi [Sun, 13 Dec 2020 02:05:30 +0000 (11:05 +0900)]
Rollup merge of #79398 - pickfire:keyword, r=Dylan-DPC
Link loop/for keyword
Even though the reference already have all of these, I am just adding related keywords in the see also to let others easily click on the related keyword.
Yuki Okushi [Sun, 13 Dec 2020 02:05:22 +0000 (11:05 +0900)]
Rollup merge of #79360 - wchargin:wchargin-doc-iter-by-reference, r=m-ou-se
std::iter: document iteration over `&T` and `&mut T`
A colleague of mine is new to Rust, and mentioned that it was “slightly
confusing” to figure out what `&mut` does in iterating over `&mut foo`:
```rust
for value in &mut self.my_vec {
// ...
}
```
My colleague had read the `std::iter` docs and not found the answer
there. There is a brief section at the top about “the three forms of
iteration”, which mentions `iter_mut`, but it doesn’t cover the purpose
of `&mut coll` for a collection `coll`. This patch adds an explanatory
section to the docs. I opted to create a new section so that it can
appear after the note that `impl<I: Iterator> IntoIterator for I`, and
it’s nice for the existing “three forms of iteration” to appear near the
top.
Test Plan:
Ran `./x.py doc library/core`, and the result looked good, including
links. Manually copy-pasted the two doctests into the playground and ran
them.
Guillaume Gomez [Sat, 12 Dec 2020 22:30:13 +0000 (23:30 +0100)]
Fixes submit event of the search input
In HTML, when a button follows an input, if the enter keep is pressed on the input, instead of sending the submit event to the input, it'll create a click event on the button following it, which in this case made the help popup show up whenever "enter" was pressed.
bors [Sat, 12 Dec 2020 23:01:25 +0000 (23:01 +0000)]
Auto merge of #79976 - jyn514:assertion-failure, r=jyn514
Remove incorrect assert
Fixes an assertion failure when resolving `::std` (or any other crate that uses the `::` style, see https://github.com/rust-lang/rust/pull/79809/files#r541776478, https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/Perf.20failing).
Camelid [Sat, 12 Dec 2020 03:52:51 +0000 (19:52 -0800)]
Resolve enum field visibility correctly
Previously, this code treated enum fields' visibility as if they were
struct fields. However, that's not correct because the visibility of a
struct field with `ast::VisibilityKind::Inherited` is private to the
module it's defined in, whereas the visibility of an *enum* field with
`ast::VisibilityKind::Inherited` is the visibility of the enum it
belongs to.
bors [Sat, 12 Dec 2020 19:41:56 +0000 (19:41 +0000)]
Auto merge of #79957 - jyn514:smaller-span, r=GuillaumeGomez
[rustdoc] Calculate span information on demand instead of storing it ahead of time
This brings `size_of<clean::types::Span>()` down from over 100 bytes (!!) to only 12, the same as rustc. It brings `Item` down even more, from `784` to `680`.
~~TODO: I need to figure out how to do this for the JSON backend too. That uses `From` impls everywhere, which don't allow passing in the `Session` as an argument. `@P1n3appl3,` `@tmandry,` maybe one of you have ideas?~~ Figured it out, fortunately only two functions needed to be changed. I like the `convert_x()` format better than `From` everywhere but I'm open to feedback.
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.~~
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)
projects / rust.git / log