bors [Sat, 20 Oct 2018 11:22:48 +0000 (11:22 +0000)]
Auto merge of #55014 - ljedrz:lazyboye_unwraps, r=matthewjasper
Prefer unwrap_or_else to unwrap_or in case of function calls/allocations
The contents of `unwrap_or` are evaluated eagerly, so it's not a good pick in case of function calls and allocations. This PR also changes a few `unwrap_or`s with `unwrap_or_default`.
An added bonus is that in some cases this change also reveals if the object it's called on is an `Option` or a `Result` (based on whether the closure takes an argument).
Douglas Campos [Fri, 19 Oct 2018 19:26:43 +0000 (19:26 +0000)]
ignore target folders
when you try to edit a crate inside the compiler tree using rls, it
generates it's assets under target/rls, then tidy is trying to validate
line lenghts for C headers, etc
David Wood [Fri, 12 Oct 2018 11:47:37 +0000 (13:47 +0200)]
Only suggest paths that exist.
In order to output a path that could actually be imported (valid and
visible), we need to handle re-exports correctly.
For example, take `std::os::unix::process::CommandExt`, this trait is
actually defined at `std::sys::unix::ext::process::CommandExt` (at time
of writing).
`std::os::unix` rexports the contents of `std::sys::unix::ext`.
`std::sys` is private so the "true" path to `CommandExt` isn't accessible.
In this case, the visible parent map will look something like this:
This is correct, as the visible parent of `std::sys::unix::ext` is in fact
`std::os`.
When printing the path to `CommandExt` and looking at the current
segment that corresponds to `std::sys::unix::ext`, we would normally
print `ext` and then go to the parent - resulting in a mangled path like
`std::os::ext::process::CommandExt`.
Instead, we must detect that there was a re-export and instead print `unix`
(which is the name `std::sys::unix::ext` was re-exported as in `std::os`).
Niko Matsakis [Wed, 17 Oct 2018 20:18:24 +0000 (16:18 -0400)]
create type ascription for any cast
Also, avoid shadowing of the `ty` variable by giving the `cast_ty` and
`var_ty` variables different names. We want to get the user-provided
type from `cast_ty.hir_id`.
Pramod Bisht [Fri, 19 Oct 2018 10:33:49 +0000 (10:33 +0000)]
Fixed: Multiple errors on single typo in match pattern
Here we have fixed the case where we were throwing two diagnostic
messages `E0026` and `E0027` for same case like this
Example
error[E0026]: variant `A::A` does not have a field named `fob`
--> src/test/ui/issue-52717.rs:20:12
|
20 | A::A { fob } => { println!("{}", fob); }
| ^^^ variant `A::A` does not have this field
error[E0027]: pattern does not mention field `foo`
--> src/test/ui/issue-52717.rs:20:5
|
20 | A::A { fob } => { println!("{}", fob); }
| ^^^^^^^^^^^^ missing field `foo`
error: aborting due to 2 previous errors
Here above we can see that both `E0026` and `E0027` are depicting
same thing.
So, to fix this issue, we are simply checking element of
`inexistent_fields` is there any value lies in
`unmentioned_fields` using Levenshtein algorithm, if does
then for that case we are simply deleting element from
`unmentioned_fields`. More or less now instead of showing
separate message in `E0027` we are giving extra hint on `E0026`
Alex Crichton [Sun, 14 Oct 2018 19:27:22 +0000 (12:27 -0700)]
rustc: Fix (again) simd vectors by-val in ABI
The issue of passing around SIMD types as values between functions has
seen [quite a lot] of [discussion], and although we thought [we fixed
it][quite a lot] it [wasn't]! This PR is a change to rustc to, again,
try to fix this issue.
The fundamental problem here remains the same, if a SIMD vector argument
is passed by-value in LLVM's function type, then if the caller and
callee disagree on target features a miscompile happens. We solve this
by never passing SIMD vectors by-value, but LLVM will still thwart us
with its argument promotion pass to promote by-ref SIMD arguments to
by-val SIMD arguments.
This commit is an attempt to thwart LLVM thwarting us. We, just before
codegen, will take yet another look at the LLVM module and demote any
by-value SIMD arguments we see. This is a very manual attempt by us to
ensure the codegen for a module keeps working, and it unfortunately is
likely producing suboptimal code, even in release mode. The saving grace
for this, in theory, is that if SIMD types are passed by-value across
a boundary in release mode it's pretty unlikely to be performance
sensitive (as it's already doing a load/store, and otherwise
perf-sensitive bits should be inlined).
The implementation here is basically a big wad of C++. It was largely
copied from LLVM's own argument promotion pass, only doing the reverse.
In local testing this...
bors [Fri, 19 Oct 2018 09:29:48 +0000 (09:29 +0000)]
Auto merge of #55194 - kennytm:rollup, r=kennytm
Rollup of 7 pull requests
Successful merges:
- #54300 (Updated RELEASES.md for 1.30.0)
- #55013 ([NLL] Propagate bounds from generators)
- #55071 (Fix ICE and report a human readable error)
- #55144 (Cleanup resolve)
- #55166 (Don't warn about parentheses on `match (return)`)
- #55169 (Add a `copysign` function to f32 and f64)
- #55178 (Stabilize slice::chunks_exact(), chunks_exact_mut(), rchunks(), rchunks_mut(), rchunks_exact(), rchunks_exact_mut())
kennytm [Fri, 19 Oct 2018 03:03:34 +0000 (11:03 +0800)]
Rollup merge of #55169 - raphlinus:copysign, r=joshtriplett
Add a `copysign` function to f32 and f64
This patch adds a `copysign` function to the float primitive types. It is an exceptionally useful function for writing efficient numeric code, as it often avoids branches, is auto-vectorizable, and there are efficient intrinsics for most platforms.
I think this might work as-is, as the relevant `copysign` intrinsic is already used internally for the implementation of `signum`. It's possible that an implementation might be needed in japaric/libm for portability across all platforms, in which case I'll do that also.
bors [Thu, 18 Oct 2018 18:14:52 +0000 (18:14 +0000)]
Auto merge of #54976 - davidtwco:issue-52663-special-case-closures, r=nikomatsakis
NLL lacks various special case handling of closures
Part of #52663.
Firstly, this PR extends existing handling of closures to also support generators.
Second, this PR adds the note found in the AST when a closure is invoked twice and captures a variable by-value:
```text
note: closure cannot be invoked more than once because it moves the variable `dict` out of its environment
--> $DIR/issue-42065.rs:16:29
|
LL | for (key, value) in dict {
| ^^^^
```
David Wood [Wed, 10 Oct 2018 19:56:17 +0000 (21:56 +0200)]
Extend closure special-casing for generators.
This commit extends existing special-casing of closures to highlight the
use of variables within generators that are causing the generator to
borrow them.
bors [Thu, 18 Oct 2018 12:47:31 +0000 (12:47 +0000)]
Auto merge of #54580 - sdroege:rchunks, r=SimonSapin
Add slice::rchunks(), rchunks_mut(), rchunks_exact() and rchunks_exact_mut()
These work exactly like the normal chunks iterators but start creating
chunks from the end of the slice.
----
The new iterators were motivated by a [comment](https://github.com/rust-lang/rust/issues/47115#issuecomment-424141121) by @DutchGhost.
~~~This currently includes the commits from https://github.com/rust-lang/rust/pull/54537 to not have to rename things twice or have merge conflicts. I'll force-push a new version of the branch ones those are in master.~~~
Also the stabilization tracking issue is just some number right now. I'll create the corresponding issue once this is reviewed and otherwise mergeable.
bors [Thu, 18 Oct 2018 07:02:11 +0000 (07:02 +0000)]
Auto merge of #55171 - kennytm:rollup, r=kennytm
Rollup of 18 pull requests
Successful merges:
- #54646 (improve documentation on std::thread::sleep)
- #54933 (Cleanup the rest of codegen_llvm)
- #54964 (Run both lldb and gdb tests)
- #55016 (Deduplicate some code and compile-time values around vtables)
- #55031 (Improve verify_llvm_ir config option)
- #55050 (doc std::fmt: the Python inspiration is already mentioned in precedin…)
- #55077 (rustdoc: Use dyn keyword when rendering dynamic traits)
- #55080 (Detect if access to localStorage is forbidden by the user's browser)
- #55090 (regression test for move out of borrow via pattern)
- #55102 (resolve: Do not skip extern prelude during speculative resolution)
- #55104 (Add test for #34229)
- #55111 ([Rustc Book] Explain --cfg's arguments)
- #55122 (Cleanup mir/borrowck)
- #55127 (Remove HybridBitSet::dummy)
- #55128 (Fix LLVMRustInlineAsmVerify return type mismatch)
- #55142 (miri: layout should not affect CTFE checks (outside of validation))
- #55151 (Cleanup nll)
- #55161 ([librustdoc] Disable spellcheck for search field)
kennytm [Thu, 18 Oct 2018 04:56:07 +0000 (12:56 +0800)]
Rollup merge of #55111 - Havvy:rustc-book-cfg-examples, r=GuillaumeGomez
[Rustc Book] Explain --cfg's arguments
I removed this from the reference since it's rustc specific, and noticed it wasn't well documented on the page that should document it well. It does seem to go against the grain of one line per command line flag though.
kennytm [Thu, 18 Oct 2018 02:47:36 +0000 (10:47 +0800)]
Rollup merge of #55142 - RalfJung:miri-uninhabited-enum, r=oli-obk
miri: layout should not affect CTFE checks (outside of validation)
Either the enum has no valid discriminant, then the code later will catch that; or it does, then we shouldn't error out so early (absent enforcing validity).
Interestingly, the miri test suite still passes; my guess is we don't even get here for uninhabited types?
kennytm [Thu, 18 Oct 2018 02:47:26 +0000 (10:47 +0800)]
Rollup merge of #55080 - thanatos:fix-localstorage-crash, r=GuillaumeGomez
Detect if access to localStorage is forbidden by the user's browser
If the user's cookie/persistent storage setting forbid access to `localStorage`, catch the exception and abort the access.
Currently, attempting to use the expand/contract links at the top of the page for structs/consts/etc. fails due to an unhandled error while accessing `localStorage`, if such access is forbidden, as the exception from the failed access propagates all the way out, interrupting the expand/contract. Instead, I would like to degrade gracefully; the access won't happen (the collapse/expand state won't get persisted) but the actual expanding/contracting of the item will go on to succeed.