Yuki Okushi [Sat, 17 Oct 2020 19:11:11 +0000 (04:11 +0900)]
Rollup merge of #78048 - blyxxyz:e0424-improve-self-placement, r=lcnr
Suggest correct place to add `self` parameter when inside closure
It would incorrectly suggest adding it as a parameter to the closure instead of the containing function.
[For example](https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=1936bcd1e5f981573386e0cee985c3c0):
```
help: add a `self` receiver parameter to make the associated `fn` a method
|
5 | let _ = || self&self;
| ^^^^^
```
`DiagnosticMetadata.current_function` is only used for these messages so tweaking its behavior should be ok.
Yuki Okushi [Sat, 17 Oct 2020 19:11:03 +0000 (04:11 +0900)]
Rollup merge of #75802 - petrochenkov:nometa, r=nikomatsakis
resolve: Do not put nonexistent crate `meta` into prelude
Before the 2018 edition release there was some vague suggestion about adding a crate named `meta` to the standard distribution.
On this basis the name `meta` was "partially reserved" by putting `meta` into extern prelude (this means importing something named `meta` will result in an ambiguity error, for example).
This only caused confusion so far, and two years later there are no specific plans to add such crate.
If some standard crate (named `meta` or not) is added in the future, then cargo will hopefully already have ability to put it into extern prelude explicitly through `Cargo.toml`.
Otherwise, it could be added to extern prelude by the compiler at edition boundary.
bors [Sat, 17 Oct 2020 06:16:00 +0000 (06:16 +0000)]
Auto merge of #77455 - asm89:faster-spawn, r=kennytm
Use posix_spawn() on unix if program is a path
Previously `Command::spawn` would fall back to the non-posix_spawn based
implementation if the `PATH` environment variable was possibly changed.
On systems with a modern (g)libc `posix_spawn()` can be significantly
faster. If program is a path itself the `PATH` environment variable is
not used for the lookup and it should be safe to use the
`posix_spawnp()` method. [1]
We found this, because we have a cli application that effectively runs a
lot of subprocesses. It would sometimes noticeably hang while printing
output. Profiling showed that the process was spending the majority of
time in the kernel's `copy_page_range` function while spawning
subprocesses. During this time the process is completely blocked from
running, explaining why users were reporting the cli app hanging.
Through this we discovered that `std::process::Command` has a fast and
slow path for process execution. The fast path is backed by
`posix_spawnp()` and the slow path by fork/exec syscalls being called
explicitly. Using fork for process creation is supposed to be fast, but
it slows down as your process uses more memory. It's not because the
kernel copies the actual memory from the parent, but it does need to
copy the references to it (see `copy_page_range` above!). We ended up
using the slow path, because the command spawn implementation in falls
back to the slow path if it suspects the PATH environment variable was
changed.
Here is a smallish program demonstrating the slowdown before this code
change:
```
use std::process::Command;
use std::time::Instant;
fn main() {
let mut args = std::env::args().skip(1);
if let Some(size) = args.next() {
// Allocate some memory
let _xs: Vec<_> = std::iter::repeat(0)
.take(size.parse().expect("valid number"))
.collect();
let mut command = Command::new("/bin/sh");
command
.arg("-c")
.arg("echo hello");
if args.next().is_some() {
println!("Overriding PATH");
command.env("PATH", std::env::var("PATH").expect("PATH env var"));
}
let now = Instant::now();
let child = command
.spawn()
.expect("failed to execute process");
println!("Spawn took: {:?}", now.elapsed());
let output = child.wait_with_output().expect("failed to wait on process");
println!("Output: {:?}", output);
} else {
eprintln!("Usage: prog [size]");
std::process::exit(1);
}
()
}
```
Running it and passing different amounts of elements to use to allocate
memory shows that the time taken for `spawn()` can differ quite
significantly. In latter case the `posix_spawnp()` implementation is 30x
faster:
Dylan DPC [Sat, 17 Oct 2020 01:27:18 +0000 (03:27 +0200)]
Rollup merge of #77932 - ssomers:btree_cleanup_gdb, r=Mark-Simulacrum
BTreeMap: improve gdb introspection of BTreeMap with ZST keys or values
I accidentally pushed an earlier revision in #77788: it changes the index of tuples for BTreeSet from ""[{}]".format(i) to "key{}".format(i). Which doesn't seem to make the slightest difference on my linux box nor on CI. In fact, gdb doesn't make any distinction between "key{}" and "val{}" for a BTreeMap either, leading to confusing output if you test more. But easy to improve.
Dylan DPC [Sat, 17 Oct 2020 01:27:12 +0000 (03:27 +0200)]
Rollup merge of #76199 - Mark-Simulacrum:void-zero, r=nikomatsakis
Permit uninhabited enums to cast into ints
This essentially reverts part of #6204; it is unclear why that [commit](https://github.com/rust-lang/rust/pull/6204/commits/c0f587de34f30b060df8a88c4068740e587b9340) was introduced, and I suspect no one remembers.
The changed code was only called from casting checks and appears to not affect any callers of that code (other than permitting this one case).
bors [Fri, 16 Oct 2020 22:53:50 +0000 (22:53 +0000)]
Auto merge of #77997 - fusion-engineering-forks:to-string-no-shrink, r=joshtriplett
Remove shrink_to_fit from default ToString::to_string implementation.
As suggested by `@scottmcm` on Zulip. shrink_to_fit() seems like the wrong thing to do here in most use cases of to_string(). Would be intereseting to see if it makes any difference in a timer run.
bors [Fri, 16 Oct 2020 20:43:27 +0000 (20:43 +0000)]
Auto merge of #78028 - JohnTitor:rollup-jt3hikb, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #75209 (Suggest imports of unresolved macros)
- #77547 (stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union')
- #77827 (Don't link to nightly primitives on stable channel)
- #77855 (resolve: further improvements to "try using the enum's variant" diagnostic)
- #77900 (Use fdatasync for File::sync_data on more OSes)
- #77925 (Suggest minimal subset features in `incomplete_features` lint)
- #77971 (Deny broken intra-doc links in linkchecker)
- #77991 (Bump backtrace-rs)
- #77992 (instrument-coverage: try our best to not ICE)
- #78013 (Fix sidebar scroll on mobile devices)
Yuki Okushi [Fri, 16 Oct 2020 20:36:54 +0000 (05:36 +0900)]
Rollup merge of #78013 - GuillaumeGomez:fix-sidebar-scroll-mobile-devices, r=jyn514
Fix sidebar scroll on mobile devices
Fixes #77942.
The issue was coming from the appearance/disappearance of the "wrapper" on the mobile devices web browsers, which triggers the "resize" event, calling the `hideSidebar` function is the JS code.
Yuki Okushi [Fri, 16 Oct 2020 20:36:52 +0000 (05:36 +0900)]
Rollup merge of #77992 - nagisa:thaw-coverage-instrumentation, r=wesleywiser
instrument-coverage: try our best to not ICE
instrument-coverage was ICEing for me on some code, in particular code
that had devirtualized paths from standard library. Instrument coverage
probably has no bussiness dictating which paths are valid and which
aren't so just feed it everything and whatever and let tooling deal with
other stuff.
For example, with this commit we can generate coverage hitpoints for
these interesting paths:
* `/rustc/.../library/core/lib.rs` – non-devirtualized path for libcore
* `/home/.../src/library/core/lib.rs` – devirtualized version of above
* `<inline asm>`, `<anon>` and many similar synthetic paths
Even if those paths somehow get to the instrumentation pass, I'd much
rather get hits for these weird paths and hope some of them work (as
would be the case for devirtualized path to libcore), rather than have
compilation fail entirely.
Yuki Okushi [Fri, 16 Oct 2020 20:36:47 +0000 (05:36 +0900)]
Rollup merge of #77925 - JohnTitor:sugg-min-features, r=davidtwco,oli-obk
Suggest minimal subset features in `incomplete_features` lint
This tells users that we have a minimal subset feature of it and they can fix the lint warning without allowing it.
The wording improvement is helpful :)
Yuki Okushi [Fri, 16 Oct 2020 20:36:45 +0000 (05:36 +0900)]
Rollup merge of #77900 - Thomasdezeeuw:fdatasync, r=dtolnay
Use fdatasync for File::sync_data on more OSes
Add support for the following OSes:
* Android
* FreeBSD: https://www.freebsd.org/cgi/man.cgi?query=fdatasync&sektion=2
* OpenBSD: https://man.openbsd.org/OpenBSD-5.8/fsync.2
* NetBSD: https://man.netbsd.org/fdatasync.2
* illumos: https://illumos.org/man/3c/fdatasync
Yuki Okushi [Fri, 16 Oct 2020 20:36:43 +0000 (05:36 +0900)]
Rollup merge of #77855 - davidtwco:pr-77341-follow-up-non-constructable-variants, r=estebank
resolve: further improvements to "try using the enum's variant" diagnostic
Follow-up on https://github.com/rust-lang/rust/pull/77341#issuecomment-702738281.
This PR improves the diagnostic modified in #77341 to suggest not only those variants which do not have fields, but those with fields (by suggesting with placeholders). In addition, the wording of the tuple-variant-only case is improved slightly.
I've not made further changes to the tuple-variant-only case (e.g. to only suggest variants with the correct number of fields) because I don't think I have enough information to do so reliably (e.g. in the case where there is an attempt to construct a tuple variant, I have no information on how many fields were provided; and in the case of pattern matching, I only have a slice of spans and would need to check for things like `..` in those spans, which doesn't seem worth it).
Yuki Okushi [Fri, 16 Oct 2020 20:36:38 +0000 (05:36 +0900)]
Rollup merge of #77547 - RalfJung:stable-union-drop, r=matthewjasper
stabilize union with 'ManuallyDrop' fields and 'impl Drop for Union'
As [discussed by @SimonSapin and @withoutboats](https://github.com/rust-lang/rust/issues/55149#issuecomment-634692020), this PR proposes to stabilize parts of the `untagged_union` feature gate:
* It will be possible to have a union with field type `ManuallyDrop<T>` for any `T`.
* While at it I propose we also stabilize `impl Drop for Union`; to my knowledge, there are no open concerns around this feature.
In the RFC discussion, we also talked about allowing `&mut T` as another non-`Copy` non-dropping type, but that felt to me like an overly specific exception so I figured we'd wait if there is actually any use for such a special case.
Some things remain unstable and still require the `untagged_union` feature gate:
* Union with fields that do not drop, are not `Copy`, and are not `ManuallyDrop<_>`. The reason to not stabilize this is to avoid semver concerns around libraries adding `Drop` implementations later. (This is already not fully semver compatible as, to my knowledge, the borrow checker will exploit the non-dropping nature of any type, but it seems prudent to avoid further increasing the amount of trouble adding an `impl Drop` can cause.)
Due to this, quite a few tests still need the `untagged_union` feature, but I think the ones where I could remove the feature flag provide good test coverage for the stable part.
instrument-coverage was ICEing for me on some code, in particular code
that had devirtualized paths from standard library. Instrument coverage
probably has no bussiness dictating which paths are valid and which
aren't so just feed it everything and whatever and let tooling deal with
other stuff.
For example, with this commit we can generate coverage hitpoints for
these interesting paths:
* `/rustc/.../library/core/lib.rs` – non-devirtualized path for libcore
* `/home/.../src/library/core/lib.rs` – devirtualized version of above
* `<inline asm>`, `<anon>` and many similar synthetic paths
Even if those paths somehow get to the instrumentation pass, I'd much
rather get hits for these weird paths and hope some of them work (as
would be the case for devirtualized path to libcore), rather than have
compilation fail entirely.
bors [Fri, 16 Oct 2020 14:06:37 +0000 (14:06 +0000)]
Auto merge of #77972 - Mark-Simulacrum:side-effect-loop, r=nagisa
Prevent miscompilation in trivial loop {}
Ideally, we would want to handle a broader set of cases to fully fix the
underlying bug here. That is currently relatively expensive at compile and
runtime, so we don't do that for now.
Performance results indicate this is not a major regression, if at all, so it should be safe to land.
`rustdoc` actually had [basic support for this](https://github.com/rust-lang/rust/blob/b1af43bc63bc7417938df056f7f25d456cc11b0e/src/librustdoc/html/static/storage.js#L121), but the setting wasn't visible and couldn't be set back once the theme was explicitly set by the user. It also didn't update if the operating system theme preference changed while viewing a page.
I'm using [this method](https://developer.mozilla.org/en-US/docs/Web/CSS/Media_Queries/Testing_media_queries#Receiving_query_notifications) to query and listen to changes to the `(prefers-color-scheme: dark)` media query. I kept the old method (based on `getComputedStyle`) as a fallback in case the user-agent doesn't support `window.matchMedia` (so like... [pretty much nobody](https://caniuse.com/?search=matchMedia)).
Since there's now more than one official ""dark"" theme in `rustdoc` (and also to support custom/third-party themes), the preferred dark and light themes can be configured in the settings page (the defaults are just "dark" and "light").
This is also my very first "proper" PR to Rust! Please let me know if I did anything wrong :).
bors [Fri, 16 Oct 2020 07:44:35 +0000 (07:44 +0000)]
Auto merge of #77666 - fusion-engineering-forks:vxworks-cleanup, r=dtolnay
Vxworks / Unix deduplication
`sys/vxworks` was almost entirely an (outdated) copy of `sys/unix`. I went through every file to check the differences and tried to figure out if they were simply outdated or intentional differences between `unix` and `vxworks`. Most of them did not have any `vxworks`-specific changes, so are deleted. I've added some minor `cfg(target_os = "vxworks")`-specific things to `sys/unix` to allow for deduplication.
Before this change, the vxworks target didn't compile because its outdated process implementation did not match the expected interface anymore. This also fixes that: `std` compiles again for `x86_64-wrs-vxworks`.
It's probably good to merge `sys/vxworks` entirely into `sys/unix`, but it might be better to to that in a follow-up PR.
bors [Fri, 16 Oct 2020 04:40:53 +0000 (04:40 +0000)]
Auto merge of #77962 - bugadani:arena2, r=Mark-Simulacrum
Remove arena's dependency on `rustc_data_structures`
`rustc_arena` currently has a dependency on `rustc_data_structures` because of a trivial "don't inline me" function. This PR copies that function and removes the dependency.
bors [Fri, 16 Oct 2020 02:27:49 +0000 (02:27 +0000)]
Auto merge of #77947 - tmiasko:promoted-scope, r=oli-obk
Create a single source scope for promoteds
A promoted inherits all scopes from the parent body. At the same time,
almost all statements and terminators inside the promoted body so far
refer only to one of those scopes: the outermost one.
Instead of inheriting all scopes, inherit only a single scope
corresponding to the location of the promoted, making sure that there
are no references to other scopes.
bors [Fri, 16 Oct 2020 00:18:13 +0000 (00:18 +0000)]
Auto merge of #78001 - Dylan-DPC:rollup-zq3kxth, r=Dylan-DPC
Rollup of 14 pull requests
Successful merges:
- #75023 (ensure arguments are included in count mismatch span)
- #75265 (Add `str::{Split,RSplit,SplitN,RSplitN,SplitTerminator,RSplitTerminator,SplitInclusive}::as_str` methods)
- #75675 (mangling: mangle impl params w/ v0 scheme)
- #76084 (Refactor io/buffered.rs into submodules)
- #76119 (Stabilize move_ref_pattern)
- #77493 (ICEs should always print the top of the query stack)
- #77619 (Use futex-based thread-parker for Wasm32.)
- #77646 (For backtrace, use StaticMutex instead of a raw sys Mutex.)
- #77648 (Static mutex is static)
- #77657 (Cleanup cloudabi mutexes and condvars)
- #77672 (Simplify doc-cfg rendering based on the current context)
- #77780 (rustc_parse: fix spans on cast and range exprs with attrs)
- #77935 (BTreeMap: make PartialCmp/PartialEq explicit and tested)
- #77980 (Fix intra doc link for needs_drop)
Dylan DPC [Fri, 16 Oct 2020 00:10:22 +0000 (02:10 +0200)]
Rollup merge of #77780 - calebcartwright:cast-expr-attr-span, r=oli-obk
rustc_parse: fix spans on cast and range exprs with attrs
Currently the span for cast and range expressions does not include the span of attributes associated to the lhs which is causing some issues for us in rustfmt.
```rust
fn foo() -> i64 {
#[attr]
1u64 as i64
}
fn bar() -> Range<i32> {
#[attr]
1..2
}
```
This corrects the span for cast and range expressions to fully include the span of child nodes
Dylan DPC [Fri, 16 Oct 2020 00:10:19 +0000 (02:10 +0200)]
Rollup merge of #77672 - Nemo157:simplify-cfg, r=jyn514
Simplify doc-cfg rendering based on the current context
For sub-items on a page don't show cfg that has already been rendered on
a parent item. At its simplest this means not showing anything that is
shown in the portability message at the top of the page, but also for
things like fields of an enum variant if that variant itself is
cfg-gated then don't repeat those cfg on each field of the variant.
This does not touch trait implementation rendering, as that is more
complex and there are existing issues around how it deals with doc-cfg
that need to be fixed first.
Dylan DPC [Fri, 16 Oct 2020 00:10:17 +0000 (02:10 +0200)]
Rollup merge of #77657 - fusion-engineering-forks:cleanup-cloudabi-sync, r=dtolnay
Cleanup cloudabi mutexes and condvars
This gets rid of lots of unnecessary unsafety.
All the AtomicU32s were wrapped in UnsafeCell or UnsafeCell<MaybeUninit>, and raw pointers were used to get to the AtomicU32 inside. This change cleans that up by using AtomicU32 directly.
Also replaces a UnsafeCell<u32> by a safer Cell<u32>.
Dylan DPC [Fri, 16 Oct 2020 00:10:15 +0000 (02:10 +0200)]
Rollup merge of #77648 - fusion-engineering-forks:static-mutex, r=dtolnay
Static mutex is static
StaticMutex is only ever used with as a static (as the name already suggests). So it doesn't have to be generic over a lifetime, but can simply assume 'static.
This 'static lifetime guarantees the object is never moved, so this is no longer a manually checked requirement for unsafe calls to lock().
Dylan DPC [Fri, 16 Oct 2020 00:10:13 +0000 (02:10 +0200)]
Rollup merge of #77646 - fusion-engineering-forks:use-static-mutex, r=dtolnay
For backtrace, use StaticMutex instead of a raw sys Mutex.
The code used the very unsafe `sys::mutex::Mutex` directly, and built its own unlock-on-drop wrapper around it. The StaticMutex wrapper already provides that and is easier to use safely.
Dylan DPC [Fri, 16 Oct 2020 00:10:11 +0000 (02:10 +0200)]
Rollup merge of #77619 - fusion-engineering-forks:wasm-parker, r=dtolnay
Use futex-based thread-parker for Wasm32.
This uses the existing `sys_common/thread_parker/futex.rs` futex-based thread parker (that was already used for Linux) for wasm32 as well (if the wasm32 atomics target feature is enabled, which is not the case by default).
Wasm32 provides the basic futex operations as instructions: https://webassembly.github.io/threads/syntax/instructions.html
These are now exposed from `sys::futex::{futex_wait, futex_wake}`, just like on Linux. So, `thread_parker/futex.rs` stays completely unmodified.
projects / rust.git / log