bors [Thu, 31 May 2018 01:06:33 +0000 (01:06 +0000)]
Auto merge of #51220 - nikomatsakis:issue-51008-false-positive-lifetime-must-be-declared, r=cramertj
reset anonymous-lifetime-mode as we enter `()` scopes
Background:
The anonymous lifetime mode is used to prohibit elided lifetimes where
they didn't used to be permitted, and instead require that `'_` be
used. For example:
```rust
impl Trait for Ref<T> { .. }
// ^^^^^^ ERROR: should be `Ref<'_, T>`
```
When we are parsing the parts of the impl header, we enter into an alternate mode called `CreateParameter`. In this mode, we give an error for things like `Ref<T>`, but for elided lifetimes in a reference type like `&T` we make the elided lifetime into an in-band lifetime:
This was not intended to change behavior because we only enter into that mode in contexts where elision was not historically permitted. However, the problem is that we fail to reset the mode when we enter into bounds like `Fn(&u32)`, where elision *was* allowed -- the same occurs for fn types like `fn(&u32`). This PR restores the original mode in those contexts.
bors [Wed, 30 May 2018 20:34:23 +0000 (20:34 +0000)]
Auto merge of #51215 - eddyb:visit-for-a-lifetime, r=nikomatsakis
rustc: don't visit lifetime parameters through visit_lifetime.
Ideally we'd also not use the `Lifetime` struct for parameters, but I'll leave that to @varkor (#48149).
Fixes #51185 (discovered while auditing all the `visit_lifetime` implementations).
r? @nikomatsakis
Niko Matsakis [Wed, 30 May 2018 14:27:53 +0000 (10:27 -0400)]
reset the "anonymous lifetime mode" for parenthesized where clauses
Background:
The anonymous lifetime mode is used to prohibit elided lifetimes where
they didn't used to be permitted, and instead require that `'_` be
used. For example:
```rust
impl Trait for Ref<T> { .. }
// ^^^^^^ ERROR: should be `Ref<'_, T>`
```
When we are parsing the parts of the impl header, we enter into an
alternate mode called `CreateParameter`. In this mode, we give an
error for things like `Ref<T>`, but for elided lifetimes in a
reference type like `&T` we make the elided lifetime into an in-band
lifetime:
This was not intended to change behavior because we only enter into
that mode in contexts where elision was not historically
permitted. However, the problem is that we fail to reset the mode when
we enter into bounds like `Fn(&u32)`, where elision *was* allowed --
the same occurs for fn types like `fn(&u32`). This PR restores the
original mode in those contexts.
bors [Wed, 30 May 2018 14:19:15 +0000 (14:19 +0000)]
Auto merge of #50955 - steveklabnik:update-libbacktrace, r=alexcrichton
Update libbacktrace
We haven't updated libbacktrace in two years. This is just blindly updating to the latest HEAD; I'd like to see what travis says. It at least builds on my machine, running some tests...
This perpetuates the patches from https://github.com/rust-lang/rust/pull/30908
Alex Crichton [Wed, 23 May 2018 02:40:02 +0000 (19:40 -0700)]
Replace libbacktrace with a submodule
While we're at it update the `backtrace` crate from crates.io. It turns out that
the submodule's configure script has gotten a lot more finnicky as of late so
also switch over to using the `cc` crate manually which allows to avoid some
hacks around the configure script as well
bors [Wed, 30 May 2018 11:35:00 +0000 (11:35 +0000)]
Auto merge of #50880 - glandium:oom, r=SimonSapin
OOM handling changes
As discussed in https://github.com/rust-lang/rust/issues/49668#issuecomment-384893456 and subsequent.
This does have codegen implications. Even without the hooks, and with a handler that ignores the arguments, the compiler doesn't eliminate calling `rust_oom` with the `Layout`. Even if it managed to eliminate that, with the hooks, I don't know if the compiler would be able to figure out it can skip it if the hook is never set.
A couple implementation notes:
- I went with explicit enums rather than bools because it makes it clearer in callers what is being requested.
- I didn't know what `feature` to put the hook setting functions behind. (and surprisingly, the compile went through without any annotation on the functions)
- There's probably some bikeshedding to do on the naming.
bors [Wed, 30 May 2018 02:11:59 +0000 (02:11 +0000)]
Auto merge of #50783 - pnkfelix:issue-27282-match-borrows-its-input-take-three, r=nikomatsakis
every match arm reads the match's borrowed input
This PR changes the `match` codegen under NLL (and just NLL, at least for now) to make the following adjustments:
* It adds a `-Z disable-ast-check-for-mutation-in-guard` which, as described, turns off the naive (conservative but also not 100% sound) check for mutation in guards of match arms.
* We now borrow the match input at the outset and emit a special `ReadForMatch` statement (that, according to the *static* semantics, reads that borrowed match input) at the start of each match arm. The intent here is to catch cases where the match guard mutates the match input, either via an independent borrow or via `ref mut` borrows in that arm's pattern.
* In order to ensure that `ref mut` borrows do not actually conflict with the emitted `ReadForMatch` statements, I expanded the two-phase-borrow system slightly, and also changed the MIR code gen so that under NLL, when there is a guard on a match arm, then each pattern variable ends up having *three* temporaries associated with it:
1. The first temporary will hold the substructure being matched; this is what we will move the (substructural) value into *if* the guard succeeds.
2. The second temporary also corresponds to the same value as the first, but we are just constructing this temporarily for use during the scope of the guard; it is unaliased and its sole referrer is the third temporary.
3. The third temporary is a reference to the second temporary.
* (This sounds complicated, I know, but its actually *simpler* than what I was doing before and had checked into the repo, which was to sometimes construct the final value and then take a reference to it before evaluating the guard. See also PR #49870.)
Fix #27282
This also provides a path towards resolving #24535 aka rust-lang/rfcs#1006, at least once the `-Z disable-ast-check-for-mutation-in-guard` is just turned on by default (under NLL, that is. It is not sound under AST-borrowck).
* But I did not want to make `#![feature(nll)]` imply that as part of this PR; that seemed like too drastic a change to me.
bors [Tue, 29 May 2018 23:49:11 +0000 (23:49 +0000)]
Auto merge of #50772 - nicokoch:fastcopy, r=alexcrichton
fs: copy: use copy_file_range on Linux
Linux 4.5 introduced a new system call [copy_file_range](http://man7.org/linux/man-pages/man2/copy_file_range.2.html) to copy data from one file to another.
This PR uses the new system call (if available). This has several advantages:
1. No need to constantly copy data from userspace to kernel space, if the buffer is small or the file is large
2. On some filesystems, like BTRFS, the kernel can leverage internal fs mechanisms for huge performance gains
3. Filesystems on the network dont need to copy data between the host and the client machine (they have to in the current read/write implementation)
I have created a small library that also implements the new system call for some huge performance gains here: https://github.com/nicokoch/fastcopy
Benchmark results are in the README
Expand two-phase-borrows so that a case like this still compiles:
```rust
fn main() {
fn reuse<X>(_: &mut X) {}
let mut t = 2f64;
match t {
ref mut _b if { false } => { reuse(_b); }
_ => {}
}
}
```
Note: The way this is currently written is confusing; when `autoref`
is off, then the arm body bindings (introduced by
`bind_matched_candidate_for_arm_body`) are *also* used for the guard.
(Any attempt to fix this needs to still ensure that the bindings used
by the guard are introduced before the guard is evaluated.)
(Once we turn NLL on by default, we can presumably simplify all of
that.)
For some reason, allowing restricted mutation in match arms exposed an
obvious case where a unique borrow can indeed fail, namely something
like:
```rust
match b {
...
ref mut r if { (|| { let bar = &mut *r; **bar = false; })(); false } => { &mut *r }
// ~~~~~~~
// |
// This ends up holding a `&unique` borrow of `r`, but there ends up being an
// implicit shared borrow in the guard thanks to rust-lang/rust#49870
...
}
```
rust-lang/rust#41962 has a new error with my new code. Incorporate that into my code.
In particular, I am adding an implicit injected borrow on the pattern
matches, and when we go around the loop, the compiler is reporting
that this injected borrow is conflicting with the move of the original
value when the match succeeds.
rust-lang/rust#27282: Add `StatementKind::ReadForMatch` to MIR.
(This is just the data structure changes and some boilerplate match
code that followed from it; the actual emission of these statements
comes in a follow-up commit.)
Debug flag to bypass restriction of mutation in match guards.
Now, if you pass `-Z disable-ast-check-for-mutation-in-guard`, then we
will just allow you to mutably-borrow and assign in guards of `match`
arms.
This is wildly unsound with AST-borrowck. It is also unsound with
MIR-borrowck without further adjustments, which come in later in the
commit series on this Pull Request.
See also rust-lang/rust#24535 and rust-lang/rfcs#1006.
Mike Hommey [Tue, 15 May 2018 00:56:46 +0000 (09:56 +0900)]
Pass a `Layout` to `oom`
As discussed in
https://github.com/rust-lang/rust/issues/49668#issuecomment-384893456
and subsequent, there are use-cases where the OOM handler needs to know
the size of the allocation that failed. The alignment might also be a
cause for allocation failure, so providing it as well can be useful.
Level 3 (possibly indirectly, the underlying bug might be in XCode’s linker) causes unit tests to sefault when compiled with some versions of XCode: https://github.com/rust-lang/rust/issues/50867
It also appears to cause some segfaults on Windows: https://github.com/rust-lang/rust/pull/50329#issuecomment-386853473, and regressions in some rustc performance benchmarks: https://github.com/rust-lang/rust/pull/50329#issuecomment-388084894
bors [Tue, 29 May 2018 12:50:06 +0000 (12:50 +0000)]
Auto merge of #51134 - RalfJung:from_raw_parts, r=SimonSapin
extend from_raw_parts docs for slices and strs to mention alignment requirement
The documentation for `str::from_raw_parts_mut` seems to not be visible because that method is private, bit I figured it could still be fixed. I also removed the reference to the no-longer-existing `str::from_raw_parts` while I was at it.
Alternatively, should I remove `str::from_raw_parts_mut` completely? it is only used in `str::split_at_mut`, where it might as well be inlined.
Level 3 (possibly indirectly, the underlying bug might be in XCode’s linker)
causes unit tests to sefault when compiled with some versions of XCode:
https://github.com/rust-lang/rust/issues/50867
It also appears to cause some segfaults on Windows:
https://github.com/rust-lang/rust/pull/50329#issuecomment-386853473
… and regressions in some rustc performance benchmarks:
https://github.com/rust-lang/rust/pull/50329#issuecomment-388084894
bors [Mon, 28 May 2018 22:28:43 +0000 (22:28 +0000)]
Auto merge of #50465 - clarcharr:wrapping, r=KodrAus
Add missing Wrapping methods, use doc_comment!
Re-opened version of #49393 . Finishing touches for #32463.
Note that this adds `Shl` and `Shr` implementations for `Wrapping<i128>` and `Wrapping<u128>`, which were previously missed. This is technically insta-stable, but I don't know why this would be a problem.
Ralf Jung [Mon, 28 May 2018 20:04:50 +0000 (22:04 +0200)]
get rid of str::from_raw_parts_mut
str::from_raw_parts has been removed long ago because it can be obtained via
str::from_utf8_unchecked and slice::from_raw_parts. The same goes for
str::from_raw_parts_mut.
bors [Mon, 28 May 2018 19:16:27 +0000 (19:16 +0000)]
Auto merge of #50929 - zackmdavis:hiridification_initiative, r=michaelwoerister
operate on `HirId` instead of `NodeId` in `hir::Pat::each_binding`, and consequences of that
See #50928 for motivation.
Questions—
* Is #50928 actually a good idea as a plan of record, or is there some reason to keep `NodeId`s?
* Are the uses of `find_node_for_hir_id` in this initial submission OK (see the FIXME comments)?
* Can we bikeshed a better method names `struct_span_lint_hir` _&c._? (Coined in analogy to the `struct_span_lint_node` and `NodeId`, but it feels kind of semantically clunky.)
bors [Mon, 28 May 2018 16:54:44 +0000 (16:54 +0000)]
Auto merge of #50521 - gnzlbg:simd_float, r=alexcrichton
Add simd math intrinsics and gather/scatter
This PR adds simd math intrinsics for floating-point vectors (sqrt, sin, cos, pow, exp, log, fma, abs, etc.) and the generic simd gather/scatter intrinsics.
Zack M. Davis [Sun, 27 May 2018 00:30:26 +0000 (17:30 -0700)]
scrap `find_node_for_hir_id` in favor of `hir_to_node_id`
Michael Woerister pointed out that `hir_to_node_id` (introduced in
August 2017's 28ddd7a4e) supersedes the functionality of
`find_node_for_hir_id` (just a hash lookup compared to that linear
search).
Zack M. Davis [Mon, 21 May 2018 03:19:34 +0000 (20:19 -0700)]
operate on `HirId` in `hir::Pat::each_binding`, and consequences of that
Changing the `each_binding` utility method to take the `HirId` of a
binding pattern rather than its `NodeId` seems like a modest first step
in support of the `HirId`ification initiative #50928. (The inspiration
for choosing this in particular came from the present author's previous
work on diagnostics issued during liveness analysis, which is the most
greatly affected module in this change.)
bors [Mon, 28 May 2018 10:11:26 +0000 (10:11 +0000)]
Auto merge of #50724 - zackmdavis:applicability_rush, r=Manishearth
add suggestion applicabilities to librustc and libsyntax
A down payment on #50723. Interested in feedback on whether my `MaybeIncorrect` vs. `MachineApplicable` judgement calls are well-calibrated (and that we have a consensus on what this means).
bors [Sun, 27 May 2018 22:28:11 +0000 (22:28 +0000)]
Auto merge of #48309 - mark-i-m:anon_param_lint, r=nikomatsakis
Make anon params lint warn-by-default
This is intended as a followup on anonymous parameters deprecation.
Cross-posting from #41686:
> After having read a bit more of the discussion that I can find, I propose a more aggressive deprecation strategy:
> - We make the lint warn-by-default as soon as possible
> - We make anon parameters a hard error at the epoch boundary