Pietro Albini [Fri, 8 Mar 2019 08:42:01 +0000 (09:42 +0100)]
Rollup merge of #58926 - gabi-250:tcx-lifetimes, r=petrochenkov
Make the lifetime parameters of tcx consistent.
I have implemented `codegen_allocator` for my backend, but I've had to make a small change to its signature in `ExtraBackendMethods`. I wonder if this change is justified, or if it is too specific to my use case to be useful to anyone else.
`write_metadata` and `codegen_allocator` are both called from `codegen_crate` (in `librustc_codegen_ssa/base.rs`), and they both receive the same `tcx` as an argument:
However, `codegen_allocator` accepts a `TyCtxt` with any lifetime parameters (`tcx: TyCtxt<'_, '_, '_>`), while `write_metadata` requires that the `tcx` argument is of type `TyCtxt<'b, 'gcx, 'gcx>`. In my implementation, I've found that it's necessary for `tcx` in `codegen_allocator` to also have the `<'b, 'gcx, 'gcx>` lifetime parameters.
Have I misunderstood the purpose of the parameters of `TyCtxt`? I've read [here](https://rust-lang.github.io/rustc-guide/ty.html) that the last two parameters only need to be distinct if the function needs to be used during type inference, but I don't think that is the case here.
Pietro Albini [Fri, 8 Mar 2019 08:42:00 +0000 (09:42 +0100)]
Rollup merge of #58921 - cuviper:issue-50582, r=varkor
Add an explicit test for issue #50582
This code no longer ICEs, and @yodaldevoid found that it was fixed by
commit fe5710a. While that added a similar test, we can explicitly test
this reproducer too.
Pietro Albini [Fri, 8 Mar 2019 08:41:50 +0000 (09:41 +0100)]
Rollup merge of #58893 - benaryorg:thread_local_example_join, r=alexcrichton
race condition in thread local storage example
The example had a potential race condition that would still pass the test.
If the thread which was supposed to modify it's own thread local was slower than the instruction to
modify in the main thread, then the test would pass even in case of a failure.
This is would be minor if the child thread was waited for since it check using an `assert_eq` for the
same thing, but vice versa.
However, if the `assert_eq` failed this would trigger a panic, which is not at all caught by the
example since the thread is not waited on.
Pietro Albini [Fri, 8 Mar 2019 08:41:38 +0000 (09:41 +0100)]
Rollup merge of #58204 - estebank:impl-trait-semi, r=zackmdavis
On return type `impl Trait` for block with no expr point at last semi
Partial solution, doesn't actually validate that the last statement in the function body can satisfy the trait bound, but it's a good incremental improvement over the status quo.
```
error[E0277]: the trait bound `(): Bar` is not satisfied
--> $DIR/impl-trait-return-trailing-semicolon.rs:3:13
|
LL | fn foo() -> impl Bar {
| ^^^^^^^^ the trait `Bar` is not implemented for `()`
LL | 5;
| - consider removing this semicolon
|
= note: the return type of a function must have a statically known size
```
bors [Fri, 8 Mar 2019 05:46:08 +0000 (05:46 +0000)]
Auto merge of #58013 - Zoxc:stable-hash-macro-simple, r=oli-obk
Create a derive macro for HashStable and allow proc macros in rustc
A combination of https://github.com/rust-lang/rust/pull/56864 and https://github.com/rust-lang/rust/pull/56795. There were complications with using `serde_derive` as rustc doesn't know which crate to use for the host when there is a serde_derive in the sysroot and cargo passes another on the command line built from crates.io.
bors [Thu, 7 Mar 2019 00:27:07 +0000 (00:27 +0000)]
Auto merge of #58583 - varkor:const-generics-ty, r=oli-obk
Add const generics to ty (and transitive dependencies)
Split out from #53645. This work is a collaborative effort with @yodaldevoid.
There are a number of stubs. Some I plan to leave for the next PRs (e.g. `infer` and `rustdoc`). Others I can either fix up in this PR, or as follow ups (which would avoid the time-consuming rebasing).
It was a little hard to split this up, as so much depends on ty and friends. Apologies for the large diff.
Josh Stone [Mon, 4 Mar 2019 21:28:31 +0000 (13:28 -0800)]
Add an explicit test for issue #50582
This code no longer ICEs, and @yodaldevoid found that it was fixed by
commit fe5710a. While that added a similar test, we can explicitly test
this reproducer too.
bors [Mon, 4 Mar 2019 04:46:38 +0000 (04:46 +0000)]
Auto merge of #58380 - estebank:missing-match-pats, r=zackmdavis
Point at enum definition when match patterns are not exhaustive
```
error[E0004]: non-exhaustive patterns: type `X` is non-empty
--> file.rs:9:11
|
1 | / enum X {
2 | | A,
| | - variant not covered
3 | | B,
| | - variant not covered
4 | | C,
| | - variant not covered
5 | | }
| |_- `X` defined here
...
9 | match x {
| ^
|
= help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms
error[E0004]: non-exhaustive patterns: `B` and `C` not covered
--> file.rs:11:11
|
1 | / enum X {
2 | | A,
3 | | B,
4 | | C,
| | - not covered
5 | | }
| |_- `X` defined here
...
11 | match x {
| ^ patterns `C` not covered
```
When a match expression doesn't have patterns covering every variant,
point at the enum's definition span. On a best effort basis, point at the
variant(s) that are missing. This does not handle the case when the missing
pattern is due to a field's enum variants:
```
enum E1 {
A,
B,
C,
}
enum E2 {
A(E1),
B,
}
fn foo() {
match E2::A(E1::A) {
E2::A(E1::B) => {}
E2::B => {}
}
//~^ ERROR `E2::A(E1::A)` and `E2::A(E1::C)` not handled
}
```
Unify look between match with no arms and match with some missing patterns.
bors [Sun, 3 Mar 2019 22:49:16 +0000 (22:49 +0000)]
Auto merge of #58505 - schomatis:fix/nll/remove-live-var, r=matthewjasper
[NLL] Remove `LiveVar`
The `LiveVar` type (and related) made it harder to reason about the code. It seemed as an abstraction that didn't bring any useful concept to the reader (when transitioning from the RFC theory to the actual implementation code).
It achieved a compactness in the vectors storing the def/use/drop information that was related only to the `LocalUseMap`. This PR went in the other direction and favored time over memory (but this decision can be easily reverted to the other side without reintroducing `LiveVar`).
What this PR aims at is to clarify that there's no significant transformation between the MIR `Local` and the `LiveVar` (now refactored as `live_locals: Vec<Local>`): we're just filtering (not mapping) the entire group of `Local`s into a meaningful subset that we should perform the liveness analysis on.
As a side note, there is no guarantee that the liveness analysis is performed only on (what the code calls) "live" variables, if the NLL facts are requested it will be performed on *any* variable so there can't be any assumptions on that regard. (Still, this PR didn't change the general naming convention to reduce the number of changes here and streamline the review process).
**Acceptance criteria:** This PR attempts to do only a minor refactoring and not to change the logic so it can't have any performance impact, particularly, it can't lose any of the significant performance improvement achieved in the great work done in https://github.com/rust-lang/rust/pull/52115.
benaryorg [Sun, 3 Mar 2019 14:21:52 +0000 (15:21 +0100)]
race condition in thread local storage example
The example had a potential race condition that would still pass the test.
If the thread which was supposed to modify it's own thread local was slower than the instruction to
modify in the main thread, then the test would pass even in case of a failure.
This is would be minor if the child thread was waited for since it check using an `assert_eq` for
the same thing, but vice versa.
However, if the `assert_eq` failed this would trigger a panic, which is not at all caught by the
example since the thread is not waited on.
bors [Sun, 3 Mar 2019 16:46:12 +0000 (16:46 +0000)]
Auto merge of #58673 - matthewjasper:typeck-ptr-coercions, r=pnkfelix
[NLL] Type check operations with pointer types
It seems these were forgotten about. Moving to `Rvalue::AddressOf` simplifies the coercions from references, but I want this to be fixed as soon as possible.
kennytm [Sun, 3 Mar 2019 05:56:57 +0000 (13:56 +0800)]
Rollup merge of #58865 - dlrobertson:fix-varargs, r=alexreg
Fix C-variadic function printing
There is no longer a need to append the string `", ..."` to a functions
args as `...` is parsed as an argument and will appear in the functions
arguments.
bors [Sun, 3 Mar 2019 03:00:16 +0000 (03:00 +0000)]
Auto merge of #58464 - jethrogb:jb/std-test-panic-output, r=alexcrichton
Use the correct stderr when testing libstd
When compiling the unit tests for libstd, there are two copies of `std` in existence, see [lib.rs](https://github.com/rust-lang/rust/blob/919cf42/src/libstd/lib.rs#L335-L341). This means there are two copies of everything, including thread local variable definitions. Before this PR, it's possible that libtest would configure a stderr sink in one of those copies, whereas the panic logic would inspect the sink in the other copy, resulting in libtest missing the relevant panic message. This PR makes sure that when testing, the panic logic always accesses the stderr sink from “realstd”, using the same logic that libtest uses.