bors [Fri, 9 Feb 2018 02:26:43 +0000 (02:26 +0000)]
Auto merge of #47489 - pnkfelix:limit-2pb-issue-46747, r=nikomatsakis
NLL: Limit two-phase borrows to autoref-introduced borrows
This imposes a restriction on two-phase borrows so that it only applies to autoref-introduced borrows.
The goal is to ensure that our initial deployment of two-phase borrows is very conservative. We want it to still cover the `v.push(v.len());` example, but we do not want it to cover cases like `let imm = &v; let mu = &mut v; mu.push(imm.len());`
(Why do we want it to be conservative? Because when you are not conservative, then the results you get, at least with the current analysis, are tightly coupled to details of the MIR construction that we would rather remain invisible to the end user.)
Fix #46747
I decided, for this PR, to add a debug-flag `-Z two-phase-beyond-autoref`, to re-enable the more general approach. But my intention here is *not* that we would eventually turn on that debugflag by default; the main reason I added it was that I thought it was useful for writing tests to be able to write source that looks like desugared MIR.
Add `AutoBorrowMutability`; its like `hir::Mutability` but w/ two-phase borrow info too.
Namely, the mutable borrows also carries a flag indicating whether
they should support two-phase borrows.
This allows us to thread down, from the point of the borrow's
introduction, whether the particular adjustment that created it is one
that yields two-phase mutable borrows.
Restrict two-phase borrows to solely borrows introduced via autoref.
Added `-Z two-phase-beyond-autoref` to bring back old behavior (mainly
to allow demonstration of desugared examples).
Updated tests to use aforementioned flag when necessary. (But in each
case where I added the flag, I made sure to also include a revision
without the flag so that one can readily see what the actual behavior
we expect is for the initial deployment of NLL.)
bors [Thu, 8 Feb 2018 06:38:30 +0000 (06:38 +0000)]
Auto merge of #48057 - scottmcm:less-match-more-compare, r=dtolnay
Simplify RangeInclusive::next[_back]
`match`ing on an `Option<Ordering>` seems cause some confusion for LLVM; switching to just using comparison operators removes a few jumps from the simple `for` loops I was trying.
cc https://github.com/rust-lang/rust/issues/45222 https://github.com/rust-lang/rust/issues/28237#issuecomment-363706510
Example:
```rust
#[no_mangle]
pub fn coresum(x: std::ops::RangeInclusive<u64>) -> u64 {
let mut sum = 0;
for i in x {
sum += i ^ (i-1);
}
sum
}
```
Today:
```asm
coresum:
xor r8d, r8d
mov r9, -1
xor eax, eax
jmp .LBB0_1
.LBB0_4:
lea rcx, [rdi - 1]
xor rcx, rdi
add rax, rcx
mov rsi, rdx
mov rdi, r10
.LBB0_1:
cmp rdi, rsi
mov ecx, 1
cmovb rcx, r9
cmove rcx, r8
test rcx, rcx
mov edx, 0
mov r10d, 1
je .LBB0_4 // 1
cmp rcx, -1
jne .LBB0_5 // 2
lea r10, [rdi + 1]
mov rdx, rsi
jmp .LBB0_4 // 3
.LBB0_5:
ret
```
With this PR:
```asm
coresum:
cmp rcx, rdx
jbe .LBB0_2
xor eax, eax
ret
.LBB0_2:
xor r8d, r8d
mov r9d, 1
xor eax, eax
.p2align 4, 0x90
.LBB0_3:
lea r10, [rcx + 1]
cmp rcx, rdx
cmovae rdx, r8
cmovae r10, r9
lea r11, [rcx - 1]
xor r11, rcx
add rax, r11
mov rcx, r10
cmp r10, rdx
jbe .LBB0_3 // Just this
ret
```
<details><summary>Though using internal iteration (`.map(|i| i ^ (i-1)).sum()`) is still shorter to type, and lets the compiler unroll it</summary>
Scott McMurray [Wed, 7 Feb 2018 19:11:54 +0000 (11:11 -0800)]
Simplify RangeInclusive::next[_back]
`match`ing on an `Option<Ordering>` seems cause some confusion for LLVM; switching to just using comparison operators removes a few jumps from the simple `for` loops I was trying.
Rollup merge of #48028 - zackmdavis:and_the_span_of_the_unknown_type, r=estebank
correct E0619 span re method call receivers whose type must be known
Previously, when the type of a method receiver could not be determined,
the error message would, potentially confusingly, highlight the span of
the entire method call.
Rollup merge of #48020 - RalfJung:type-alias-bounds, r=petrochenkov
Warn about more ignored bounds in type aliases
It seems that all bounds in type aliases are entirely ignored, not just type bounds. This extends the warning appropriately.
I assume this should be made a hard error with the next epoch? I can't see any reason to accept these programs. (And suddenly enforcing these type bounds would be a breaking change.)
Rollup merge of #48018 - alexcrichton:require-const-arg, r=eddyb
rustc: Add `#[rustc_args_required_const]`
This commit adds a new unstable attribute to the compiler which requires that
arguments to a function are always provided as constants. The primary use case
for this is SIMD intrinsics where arguments are defined by vendors to be
constant and in LLVM they indeed must be constant as well.
For now this is mostly just a semantic guarantee in rustc that an argument is a
constant when invoked, phases like trans don't actually take advantage of it
yet. This means that we'll be able to use this in stdsimd but we won't be able
to remove the `constify_*` macros just yet. Hopefully soon though!
Rollup merge of #48014 - Manishearth:stealing-chickens-on-the-internet, r=nikomatsakis
Implement RFC 2052 (Epochs)
This adds -Zepochs and uses it for tyvar_behind_raw_pointer (#46906)
When we move this to --epoch=XXX, we'll need to gate the 2018 epoch on nightly, but not the 2015 one. I can make these changes here itself though it's kinda pointless given that the entire flag is nightly-only.
r? @nikomatsakis @aturon
cc #44581 (epoch tracking)
cc #46906 (tyvar_behind_raw_pointer)
Rollup merge of #47944 - oberien:unboundediterator-trustedlen, r=bluss
Implement TrustedLen for Take<Repeat> and Take<RangeFrom>
This will allow optimization of simple `repeat(x).take(n).collect()` iterators, which are currently not vectorized and have capacity checks.
This will only support a few aggregates on `Repeat` and `RangeFrom`, which might be enough for simple cases, but doesn't optimize more complex ones. Namely, Cycle, StepBy, Filter, FilterMap, Peekable, SkipWhile, Skip, FlatMap, Fuse and Inspect are not marked `TrustedLen` when the inner iterator is infinite.
Rollup merge of #47883 - yurydelendik:wasm-map, r=alexcrichton
Export wasm source map when debug information is enabled
We use binaryen's linker to produce a wasm file (via s2wasm). The wasm writer has capabilities to export source maps. The pilot support for source maps is added to Firefox.
The produced source map contains references to the original file, that might require additional source map file processing to include / package original files with it.
Rollup merge of #47631 - SimonSapin:nonnull, r=alexcrichton
Add some APIs to ptr::NonNull and fix `since` attributes
This is a follow-up to its stabilization in https://github.com/rust-lang/rust/pull/46952. Tracking issue: https://github.com/rust-lang/rust/issues/27730.
* These trait impls are insta-stable: `Hash`, `PartialEq`, `Eq`, `PartialOrd` and `Ord`.
* The new `cast<U>() -> NonNull<U>` method is `#[unstable]`. It was proposed in https://github.com/rust-lang/rust/pull/46952#issuecomment-359220010.
Rollup merge of #47613 - estebank:rustc_on_unimplemented, r=nikomatsakis
Add filtering options to `rustc_on_unimplemented`
- Add filtering options to `rustc_on_unimplemented` for local traits, filtering on `Self` and type arguments.
- Add a way to provide custom notes.
- Tweak binops text.
- Add filter to detect wether `Self` is local or belongs to another crate.
- Add filter to `Iterator` diagnostic for `&str`.
Partly addresses #44755 with a different syntax, as a first approach. Fixes #46216, fixes #37522, CC #34297, #46806.
bors [Wed, 7 Feb 2018 14:54:15 +0000 (14:54 +0000)]
Auto merge of #47957 - bobtwinkles:fix_mir_consts, r=nikomatsakis
[NLL] Improve DefiningTy::Const
Fixes #47590 by fixing the way DefiningTy represents constants. Previously, constants were represented using just the type of the variable. However, this will fail to capture early-bound regions as NLL inference vars, resulting in an ICE when we try to compute region VIDs a little bit later in the universal
region resolution process. (ref #47590)
bobtwinkles [Fri, 2 Feb 2018 03:26:48 +0000 (22:26 -0500)]
mir: Fix DefiningTy::Const
Fixes #47590 by fixing the way DefiningTy represents constants. Previously,
constants were represented using just the type of the variable. However, this
will fail to capture early-bound regions as NLL inference vars, resulting in an
ICE when we try to compute region VIDs a little bit later in the universal
region resolution process.
Fixes #45697. This PR resolves the error duplication. I attempted to replace the existing sets since there were quite a few but only managed to replace two of them.
kennytm [Tue, 6 Feb 2018 19:23:26 +0000 (03:23 +0800)]
Rollup merge of #48013 - onur:use-time-in-bootstrap-dist, r=alexcrichton
Use time crate in bootstrap dist instead of date
`bootstrap dist` command is trying to run *NIX specific `date` command to get current month and year. This command keep failing when it's called on a Windows command prompt. This patch is making it use time crate.
kennytm [Tue, 6 Feb 2018 19:23:25 +0000 (03:23 +0800)]
Rollup merge of #48012 - scottmcm:faster-rangeinclusive-fold, r=alexcrichton
Override try_[r]fold for RangeInclusive
Because the last item needs special handling, it seems that LLVM has trouble canonicalizing the loops in external iteration. With the override, it becomes obvious that the start==end case exits the loop (as opposed to the one *after* that exiting the loop in external iteration).
kennytm [Tue, 6 Feb 2018 19:23:24 +0000 (03:23 +0800)]
Rollup merge of #47986 - Gilnaa:libtest_relaxed, r=Mark-Simulacrum
libtest: Replace panics with error messages
This replaces explicit panics on failures in libtest with prints to stderr.
Where "failures" == CLI argument parsing and such
Before:
```
$ ./foo-stable --not-an-option
thread 'main' panicked at '"Unrecognized option: \'not-an-option\'"', libtest/lib.rs:251:27
note: Run with `RUST_BACKTRACE=1` for a backtrace.
```
kennytm [Tue, 6 Feb 2018 19:23:23 +0000 (03:23 +0800)]
Rollup merge of #46962 - clarcharr:os_raw_docs, r=QuietMisdreavus
Document std::os::raw.
This adds a brief explanation to each type and its definition according to C. This also helps clarify that the definitions of the types, as described by rustdoc, are not necessarily the same from platform to platform.
bors [Tue, 6 Feb 2018 09:51:03 +0000 (09:51 +0000)]
Auto merge of #47203 - varkor:output-filename-conflicts-with-directory, r=estebank
Warn when rustc output conflicts with existing directories
When the compiled executable would conflict with a directory, display a
rustc error instead of a verbose and potentially-confusing linker
error. This is a usability improvement, and doesn’t actually change
behaviour with regards to compilation success. This addresses the
concern in #35887. Fixes #13098.
Zack M. Davis [Tue, 6 Feb 2018 02:09:51 +0000 (18:09 -0800)]
correct E0619 span re method call receivers whose type must be known
Previously, when the type of a method receiver could not be determined,
the error message would, potentially confusingly, highlight the span of
the entire method call.
Alex Crichton [Mon, 5 Feb 2018 18:48:22 +0000 (10:48 -0800)]
rustc: Add `#[rustc_args_required_const]`
This commit adds a new unstable attribute to the compiler which requires that
arguments to a function are always provided as constants. The primary use case
for this is SIMD intrinsics where arguments are defined by vendors to be
constant and in LLVM they indeed must be constant as well.
For now this is mostly just a semantic guarantee in rustc that an argument is a
constant when invoked, phases like trans don't actually take advantage of it
yet. This means that we'll be able to use this in stdsimd but we won't be able
to remove the `constify_*` macros just yet. Hopefully soon though!
kennytm [Mon, 5 Feb 2018 18:13:45 +0000 (02:13 +0800)]
Rollup merge of #47496 - QuietMisdreavus:rls-doc-include, r=estebank
add documentation from doc(include) to analysis data
cc #44732
Currently save-analysis only loads docs from plain doc comments and doc attributes. Since `#[doc(include="filename.md")]` doesn't create a plain doc attribute when it loads the file, we need to be sure to pick up this info for the analysis data.
bors [Mon, 5 Feb 2018 15:05:43 +0000 (15:05 +0000)]
Auto merge of #47881 - oli-obk:miri_clippy, r=Manishearth
Update clippy and miri submodule
r? @Manishearth
cc @kennytm I needed to touch the miri submodule's Cargo.toml to make sure that clippy gets the newest compiletest_rs. This will not fix miri, but since I touched the miri submodule, will this PR fail?
bors [Mon, 5 Feb 2018 09:17:00 +0000 (09:17 +0000)]
Auto merge of #47920 - Aaron1011:nll-overflow, r=pnkfelix
Fix overflow when performing drop check calculations in NLL
Clearing out the infcx's region constraints after processing each type
ends up interacting badly with normalizing associated types. This commit
keeps all region constraints intact until the end of
TypeLivenessGenerator.add_drop_live_constraint, ensuring that normalized
types are able to re-use existing inference variables.
Scott McMurray [Mon, 5 Feb 2018 07:48:40 +0000 (23:48 -0800)]
Override try_[r]fold for RangeInclusive
Because the last item needs special handling, it seems that LLVM has trouble canonicalizing the loops in external iteration. With the override, it becomes obvious that the start==end case exits the loop (as opposed to the one *after* that exiting the loop in external iteration).
bors [Mon, 5 Feb 2018 04:32:06 +0000 (04:32 +0000)]
Auto merge of #47873 - Aaron1011:final-ref-coerce, r=nikomatsakis
Fix ref-to-ptr coercions not working with NLL in certain cases
Implicit coercions from references to pointers were lowered to slightly
different Mir than explicit casts (e.g. 'foo as *mut T'). This resulted
in certain uses of self-referential structs compiling correctly when an
explicit cast was used, but not when the implicit coercion was used.
To fix this, this commit adds an outer 'Use' expr when applying a
raw-ptr-borrow adjustment. This makes the lowered Mir for coercions
identical to that of explicit coercions, allowing the original code to
compile regardless of how the raw ptr cast occurs.
bors [Mon, 5 Feb 2018 01:45:46 +0000 (01:45 +0000)]
Auto merge of #47865 - Manishearth:cleanup-shim, r=nikomatsakis
Cleanup the shim code
- We now write directly to `RETURN_PLACE` instead of creating intermediates
- `tuple_like_shim` takes an iterator (used by #47867)
- `tuple_like_shim` no longer relies on it being the first thing to create blocks, and uses relative block indexing in a cleaner way (necessary for #47867)
- All the shim builders take `dest, src` arguments instead of hardcoding RETURN_PLACE
kennytm [Sun, 4 Feb 2018 17:27:36 +0000 (01:27 +0800)]
Rollup merge of #47892 - Badel2:const_type_id_of, r=oli-obk
Turn `type_id` into a constant intrinsic
https://github.com/rust-lang/rust/issues/27745
The method `get_type_id` in `Any` is intended to support reflection. It's currently unstable in favor of using an associated constant instead. This PR makes the `type_id` intrinsic a constant intrinsic, the same as `size_of` and `align_of`, allowing `TypeId::of` to be a `const fn`, which will allow using an associated constant in `Any`.
kennytm [Sun, 4 Feb 2018 15:29:01 +0000 (23:29 +0800)]
Rollup merge of #47978 - eddyb:iu, r=kennytm
ui tests: diff from old (expected) to new (actual) instead of backwards.
Previously `actual` was "old" and `expected` was "new" which resulted in `+` before `-`.
AFAIK all diff tools put `-` before `+`, which made the previous behavior *very confusing*.
kennytm [Sun, 4 Feb 2018 15:28:57 +0000 (23:28 +0800)]
Rollup merge of #47912 - cuviper:glibc-stack-guard, r=alexcrichton
Use a range to identify SIGSEGV in stack guards
Previously, the `guard::init()` and `guard::current()` functions were
returning a `usize` address representing the top of the stack guard,
respectively for the main thread and for spawned threads. The `SIGSEGV`
handler on `unix` targets checked if a fault was within one page below that
address, if so reporting it as a stack overflow.
Now `unix` targets report a `Range<usize>` representing the guard memory,
so it can cover arbitrary guard sizes. Non-`unix` targets which always
return `None` for guards now do so with `Option<!>`, so they don't pay any
overhead.
For `linux-gnu` in particular, the previous guard upper-bound was
`stackaddr + guardsize`, as the protected memory was *inside* the stack.
This was a glibc bug, and starting from 2.27 they are moving the guard
*past* the end of the stack. However, there's no simple way for us to know
where the guard page actually lies, so now we declare it as the whole range
of `stackaddr ± guardsize`, and any fault therein will be called a stack
overflow. This fixes #47863.
kennytm [Sun, 4 Feb 2018 15:28:56 +0000 (23:28 +0800)]
Rollup merge of #47896 - zackmdavis:and_the_case_of_the_necessary_unnecessary_parens, r=nikomatsakis
decline to lint technically-unnecessary parens in function or method arguments inside of nested macros
In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.
We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.
It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.
bors [Sun, 4 Feb 2018 03:33:44 +0000 (03:33 +0000)]
Auto merge of #47915 - eddyb:layout-of, r=nikomatsakis
rustc: prefer ParamEnvAnd and LayoutCx over tuples for LayoutOf.
This PR provides `tcx.layout_of(param_env.and(ty))` as the idiomatic replacement for the existing `(tcx, param_env).layout_of(ty)` and removes fragile (coherence-wise) layout-related tuple impls.
Mark Simulacrum [Sun, 28 Jan 2018 22:50:03 +0000 (15:50 -0700)]
Disable ThinLTO for dist builds.
Dist builds should always be as fast as we can make them, and since
those run on CI we don't care quite as much for the build being somewhat
slower. As such, we don't automatically enable ThinLTO on builds for the
dist builders.