bors [Mon, 22 Oct 2018 03:41:28 +0000 (03:41 +0000)]
Auto merge of #55224 - kryptan:master, r=matthewjasper
Use a keyword in raw identifier example
That's a very small documentation fix. The text says "you can now use keywords as identifiers" but example didn't use a keyword and would work without raw identifiers.
bors [Sun, 21 Oct 2018 12:04:25 +0000 (12:04 +0000)]
Auto merge of #55069 - matthewjasper:explain-free-region-liveness, r=nikomatsakis
[NLL] Use new region infer errors when explaining borrows
Use the new free region infer errors for explaining borrows
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure to a captured variable. (E0521)
Closes #51026 - `regions-nested-fns-2.rs` isn't changed to that diagnostic, since that would not be the correct error here.
Closes #51169
cc #53882 - The error is (IMO) better now, but it could be better when we trace lifetimes in these error messages.
Matthew Jasper [Sun, 14 Oct 2018 14:12:02 +0000 (15:12 +0100)]
Use new region infer errors for explaining borrows
This gives at least some explanation for why a borrow is expected to
last for a certain free region. Also:
* Reports E0373: "closure may outlive the current function" with NLL.
* Special cases the case of returning a reference to (or value
referencing) a local variable or temporary (E0515).
* Special case assigning a reference to a local variable in a closure
to a captured variable.
bors [Sun, 21 Oct 2018 06:48:10 +0000 (06:48 +0000)]
Auto merge of #54919 - alexcrichton:update-cargo, r=Mark-Simulacrum
Update Cargo, build curl/OpenSSL statically via features
In addition to to updating Cargo's submodule and Cargo's dependencies,
this also updates Cargo's build to build OpenSSL statically into Cargo
as well as libcurl unconditionally. This removes OpenSSL build logic
from the bootstrap code, and otherwise requests that even on OSX we
build curl statically.
Alex Crichton [Mon, 8 Oct 2018 17:39:09 +0000 (10:39 -0700)]
Update Cargo, build curl/OpenSSL statically via features
In addition to to updating Cargo's submodule and Cargo's dependencies,
this also updates Cargo's build to build OpenSSL statically into Cargo
as well as libcurl unconditionally. This removes OpenSSL build logic
from the bootstrap code, and otherwise requests that even on OSX we
build curl statically.
bors [Sat, 20 Oct 2018 22:23:36 +0000 (22:23 +0000)]
Auto merge of #55230 - Manishearth:rollup, r=Manishearth
Rollup of 5 pull requests
Successful merges:
- #55156 (Fixed: Multiple errors on single typo in match pattern)
- #55189 (update books for the next release)
- #55193 (make asm diagnostic instruction optional)
- #55203 (Write an initial version of the `program_clauses` callback)
- #55213 (ignore target folders)
Matthew Jasper [Sat, 13 Oct 2018 13:23:23 +0000 (14:23 +0100)]
Use more accurate `ConstraintCategory`s
Adds UseAsConst and UseAsStatic to replace Return in consts/statics.
Don't report the arguments to an overloaded operator as CallArguments.
Also don't report "escaping data" in these items.
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
Rollup merge of #55073 - alexcrichton:demote-simd, r=nagisa
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 [Sat, 20 Oct 2018 19:45:53 +0000 (19:45 +0000)]
Auto merge of #55156 - PramodBisht:issue/52717, r=estebank
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.
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 if for last element of `inexistent_fields` is there any value lies in `unmentioned_fields` using levenshtein algorithm, if it 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`
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.
projects / rust.git / log