bors [Sun, 3 Nov 2019 18:36:59 +0000 (18:36 +0000)]
Auto merge of #65646 - Amanieu:foreign-exceptions, r=nikomatsakis
Allow foreign exceptions to unwind through Rust code and Rust panics to unwind through FFI
This PR fixes interactions between Rust panics and foreign (mainly C++) exceptions.
C++ exceptions (and other FFI exceptions) can now safely unwind through Rust code:
- The FFI function causing the unwind must be marked with `#[unwind(allowed)]`. If this is not the case then LLVM may optimize landing pads away with the assumption that they are unreachable.
- Drop code will be executed as the exception unwinds through the stack, as with a Rust panic.
- `catch_unwind` will *not* catch the exception, instead the exception will silently continue unwinding past it.
Rust panics can now safely unwind through C++ code:
- C++ destructors will be called as the stack unwinds.
- The Rust panic can only be caught with `catch (...)`, after which it can be either rethrown or discarded.
- C++ cannot name the type of the Rust exception object used for unwinding, which means that it can't be caught explicitly or have its contents inspected.
Tests have been added to ensure all of the above works correctly.
Some notes about non-C++ exceptions:
- `pthread_cancel` and `pthread_exit` use unwinding on glibc. This has the same behavior as a C++ exception: destructors are run but it cannot be caught by `catch_unwind`.
- `longjmp` on Windows is implemented using unwinding. Destructors are run on MSVC, but not on MinGW. In both cases the unwind cannot be caught by `catch_unwind`.
- As with C++ exceptions, you need to mark the relevant FFI functions with `#[unwind(allowed)]`, otherwise LLVM will optimize out the destructors since they seem unreachable.
I haven't updated any of the documentation, so officially unwinding through FFI is still UB. However this is a step towards making it well-defined.
bors [Sun, 3 Nov 2019 15:14:09 +0000 (15:14 +0000)]
Auto merge of #65759 - tmiasko:ui, r=petrochenkov
Validate error patterns and error annotation in ui tests when present
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
Tomasz Miąsko [Tue, 29 Oct 2019 00:00:00 +0000 (00:00 +0000)]
Avoid matching type in huge-struct test error annotation
The concrete type that will be too big is target dependent. Avoid
matching it in error annotation to make test work correctly across
different targets.
Tomasz Miąsko [Thu, 24 Oct 2019 00:00:00 +0000 (00:00 +0000)]
Validate error patterns and error annotation in ui tests when present
Previously, when compilation succeeded, neither error patterns nor error
annotation would be validated. Additionally, when compilation failed,
only error patterns would be validated if both error patterns and error
annotation were present.
Now both error patterns and error annotation are validated when present,
regardless of compilation status. Furthermore, for test that should run,
the error patterns are matched against executable output, which is what
some of tests already expect to happen, and when #65506 is merged even
more ui tests will.
Tomasz Miąsko [Thu, 24 Oct 2019 00:00:00 +0000 (00:00 +0000)]
Update error annotations positions
Since 8ec9d7242c3352fbc617d907bec3632215811356, in the case of a local
macro expansion, the errors are now matched to macro definition
location. Update test cases accordingly.
bors [Sun, 3 Nov 2019 08:01:29 +0000 (08:01 +0000)]
Auto merge of #65779 - kevgrasso:E0308highlight, r=estebank
Highlight only relevant parts of type path in type errors
Resolves #57413.
Unfortunately the current Rust UI testing setup can't test that the correct colors are being used in a given output, so here's a screenshot of a small test program I wrote:
![image](https://user-images.githubusercontent.com/480789/67530063-f272af00-f68b-11e9-9f96-a211fc7666d4.png)
bors [Sat, 2 Nov 2019 10:48:59 +0000 (10:48 +0000)]
Auto merge of #66004 - eddyb:revert-early-gate, r=petrochenkov
Partially revert the early feature-gatings added in #65742.
The intent here is to address #65860 ASAP (in time for beta, ideally), while leaving as much of #65742 around as possible, to make it easier to re-enable later.
Therefore, I've only kept the parts of the revert that re-add the old (i.e. non-early) feature-gating checks that were removed in #65742, and the test reverts.
I've disabled the new early feature-gating checks from #65742 entirely for now, but it would be easy to put them behind a `-Z` flag, or turn them into warnings, which would allow us to keep tests for both the early and late versions of the checks - assuming that's desirable.
Tomasz Miąsko [Thu, 24 Oct 2019 00:00:00 +0000 (00:00 +0000)]
Update error annotations in tests that successfully compile
Those annotation are silently ignored rather than begin validated
against compiler output. Update them before validation is enabled,
to avoid test failures.
bors [Fri, 1 Nov 2019 18:23:04 +0000 (18:23 +0000)]
Auto merge of #66021 - tmandry:rollup-y13l6n9, r=tmandry
Rollup of 16 pull requests
Successful merges:
- #65112 (Add lint and tests for unnecessary parens around types)
- #65470 (Don't hide ICEs from previous incremental compiles)
- #65471 (Add long error explanation for E0578)
- #65857 (rustdoc: Resolve module-level doc references more locally)
- #65902 (Make ItemContext available for better diagnositcs)
- #65914 (Use structured suggestion for unnecessary bounds in type aliases)
- #65946 (Make `promote_consts` emit the errors when required promotion fails)
- #65960 (doc: reword iter module example and mention other methods)
- #65963 (update submodules to rust-lang)
- #65972 (Fix libunwind build: Define __LITTLE_ENDIAN__ for LE targets)
- #65977 (Fix incorrect diagnostics for expected type in E0271 with an associated type)
- #65995 (Add error code E0743 for "C-variadic has been used on a non-foreign function")
- #65997 (Fix outdated rustdoc of Once::init_locking function)
- #66002 (Stabilize float_to_from_bytes feature)
- #66005 (vxWorks: remove code related unix socket)
- #66018 (Revert PR 64324: dylibs export generics again (for now))
Tyler Mandry [Fri, 1 Nov 2019 18:20:29 +0000 (11:20 -0700)]
Rollup merge of #66018 - pnkfelix:issue-64872-revert-64324, r=alexcrichton
Revert PR 64324: dylibs export generics again (for now)
As discussed on PR #65781, this is a targeted attempt to undo the main semantic change from PR #64324, by putting `dylib` back in the set of crate types that export generic symbols.
The main reason to do this is that PR #64324 had unanticipated side-effects that caused bugs like #64872, and in the opinion of @alexcrichton and myself, the impact of #64872 is worse than #64319.
In other words, it is better for us, in the short term, to reopen #64319 as currently unfixed for now than to introduce new bugs like #64872.
Tyler Mandry [Fri, 1 Nov 2019 18:20:22 +0000 (11:20 -0700)]
Rollup merge of #65977 - ohadravid:fix-incorrect-diagnostics-with-an-associated-type, r=estebank
Fix incorrect diagnostics for expected type in E0271 with an associated type
With code like the following code:
```rust
#[derive(Debug)]
struct Data {}
fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
for item in iterator {
println!("{:?}", item)
}
}
fn main() {
let v = vec![Data {}];
do_stuff(v.into_iter());
}
```
the diagnostic (in nightly & stable) wrongly complains about the expected type:
```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
--> src/main.rs:15:5
|
5 | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
| -------- --------------- required by this bound in `do_stuff`
...
15 | do_stuff(v.into_iter());
| ^^^^^^^^ expected struct `Data`, found &Data
|
= note: expected type `Data`
found type `&Data`
```
This PR fixes this issue by flipping the expected/actual values where appropriate, so it looks like this:
```
error[E0271]: type mismatch resolving `<std::vec::IntoIter<Data> as std::iter::Iterator>::Item == &Data`
--> main.rs:15:5
|
5 | fn do_stuff<'a>(iterator: impl Iterator<Item = &'a Data>) {
| -------- --------------- required by this bound in `do_stuff`
...
15 | do_stuff(v.into_iter());
| ^^^^^^^^ expected &Data, found struct `Data`
|
= note: expected type `&Data`
found type `Data`
```
This improves the output of a lot of existing tests (check out `associated-types-binding-to-type-defined-in-supertrait`!).
The only change which I wasn't too sure about is in the test `associated-types-overridden-binding-2`, but I think it's an improvement and the underlying problem is with handling of `trait_alias`.
Tyler Mandry [Fri, 1 Nov 2019 18:20:21 +0000 (11:20 -0700)]
Rollup merge of #65972 - braiins:vkr-arm-panicking, r=alexcrichton
Fix libunwind build: Define __LITTLE_ENDIAN__ for LE targets
If `__LITTLE_ENDIAN__` is missing, libunwind assumes big endian
and reads unwinding instructions wrong on ARM EHABI.
Fix #65765
Technical background in referenced bug.
I didn't run any automated tests, just built a simple panicking program using the fixed toolchain and panicking started to work. Tried with `catch_unwind()` and that seems to work now too. libunwind's log seems ok now, I can paste it if needed.
Tyler Mandry [Fri, 1 Nov 2019 18:20:17 +0000 (11:20 -0700)]
Rollup merge of #65946 - ecstatic-morse:refactor-promotion2, r=eddyb
Make `promote_consts` emit the errors when required promotion fails
A very minimal version of #65942.
This will cause a generic "argument X is required to be a constant" message for `simd_shuffle` LLVM intrinsics instead of the [custom one](https://github.com/rust-lang/rust/blob/caa1f8d7b3b021c86a70ff62d23a07d97acff4c4/src/librustc_mir/transform/qualify_consts.rs#L1616). It may be possible to remove this special-casing altogether after rust-lang/stdarch#825.
Tyler Mandry [Fri, 1 Nov 2019 18:20:12 +0000 (11:20 -0700)]
Rollup merge of #65857 - kinnison:kinnison/issue-55364, r=Manisheart,GuillaumeGomez
rustdoc: Resolve module-level doc references more locally
Module level docs should resolve intra-doc links as locally as
possible. As such, this commit alters the heuristic for finding
intra-doc links such that we attempt to resolve names mentioned
in *inner* documentation comments within the (sub-)module rather
that from the context of its parent.
I'm hoping that this fixes #55364 though right now I'm not sure it's the right fix.
Tyler Mandry [Fri, 1 Nov 2019 18:20:09 +0000 (11:20 -0700)]
Rollup merge of #65470 - traxys:fix_65401, r=michaelwoerister
Don't hide ICEs from previous incremental compiles
I think this fixes #65401, the compiler does not fail to ICE after the first compilation, tested on the last snippet of [this comment](https://github.com/rust-lang/rust/issues/63154#issuecomment-541592381).
I am not very sure of the fix as I don't understand much of the structure of the compiler.
Tyler Mandry [Fri, 1 Nov 2019 18:20:07 +0000 (11:20 -0700)]
Rollup merge of #65112 - jack-t:type-parens-lint, r=varkor
Add lint and tests for unnecessary parens around types
This is my first contribution to the Rust project, so I apologize if I'm not doing things the right way.
The PR fixes #64169. It adds a lint and tests for unnecessary parentheses around types. I've run `tidy` and `rustfmt` — I'm not totally sure it worked right, though — and I've tried to follow the instructions linked in the readme.
I tried to think through all the variants of `ast::TyKind` to find exceptions to this lint, and I could only find the one mentioned in the original issue, which concerns types with `dyn`. I'm not a Rust expert, thought, so I may well be missing something.
There's also a problem with getting this to build. The new lint catches several things in the, e.g., `core`. Because `x.py` seems to build with an equivalent of `-Werror`, what would have been warnings cause the build to break. I got it to build and the tests to pass with `--warnings warn` on my `x.py build` and `x.py test` commands.
ui test formulation of regression test for issue 64872.
(Many thanks to alex for 1. making this even smaller than what I had
originally minimized, and 2. pointing out that there is precedent for
having ui tests with crate dependency chains of length > 2, thus
allowing me to avoid encoding this as a run-make test.)
bors [Fri, 1 Nov 2019 11:34:51 +0000 (11:34 +0000)]
Auto merge of #65718 - eddyb:codegen-var-debuginfo, r=nikomatsakis
rustc_codegen_ssa: introduce MIR VarDebugInfo, but only for codegen.
These are all the codegen changes necessary for #56231.
The refactors were performed locally to codegen, and in several steps, to ease reviewing and avoid introducing changes in behavior (as I'm not sure our debuginfo tests cover enough).
bors [Fri, 1 Nov 2019 06:35:40 +0000 (06:35 +0000)]
Auto merge of #65698 - msizanoen1:dual-proc-macro-hash, r=petrochenkov
Dual proc macro hash
This PR changes current `-Z dual-proc-macro` mechanism from resolving only by name to including the hash of the host crate inside the transistive dependency information to prevent name conflicts.
Fix partially #62558
bors [Fri, 1 Nov 2019 03:15:31 +0000 (03:15 +0000)]
Auto merge of #65459 - ecstatic-morse:graphviz-subgraph, r=estebank
Fix `-Zunpretty=mir-cfg` to render multiple items
`-Zunpretty=mir-cfg` outputs DOT to stdout for all items being compiled. However, it puts all of these items in separate `digraph`s, which means the result of redirecting that output to a file is not valid. Most dot renderers (I have tried `dot` and `xdot`) cannot render the output.
This PR checks to see if `write_mir_graphviz` will process multiple items, and writes them each as a `subgraph` in a single, top-level `digraph`. As a result, DOT can be viewed without manually editing the output file. The output is unchanged when printing a single item (e.g.`-Zunpretty=mir-cfg=item_name`).
Here's the output of `xdot` for a rust file containing three items:
![three-items](https://user-images.githubusercontent.com/29463364/66889712-4bf62200-ef98-11e9-83b5-60faa2a300dd.png)
The borders are a result of the nonstandard–but well-supported–[`cluster` prefix](https://graphviz.gitlab.io/_pages/doc/info/lang.html) (search for "Subgraphs and Clusters"). They will not appear if your renderer does not support this extension, but the graph will still render properly.
bors [Thu, 31 Oct 2019 15:15:53 +0000 (15:15 +0000)]
Auto merge of #65091 - sekineh:into-iter-sorted, r=KodrAus
Implement ordered/sorted iterators on BinaryHeap as per #59278
I've implemented the ordered version of iterator on BinaryHeap as per #59278.
# Added methods:
* `.into_iter_sorted()`
* like `.into_iter()`; but returns elements in heap order
* `.drain_sorted()`
* like `.drain()`; but returns elements in heap order
* It's a bit _lazy_; elements are removed on drop. (Edit: it’s similar to vec::Drain)
For `DrainSorted` struct, I implemented `Drop` trait following @scottmcm 's [suggestion](https://github.com/rust-lang/rust/issues/59278#issuecomment-537306925)
# ~TODO~ DONE
* ~I think I need to add more tests other than doctest.~
# **Notes:**
* we renamed `_ordered` to `_sorted`, because the latter is more common in rust libs. (as suggested by @KodrAus )
bors [Thu, 31 Oct 2019 11:51:42 +0000 (11:51 +0000)]
Auto merge of #63803 - GuillaumeGomez:stabilize-doctest, r=ollie27,QuietMisdreavus,Mark-Simulacrum
[rustdoc] stabilize cfg(doctest)
Fixes #62210.
Since we removed rustdoc from providing cfg(test) on test runs, it's been replaced by cfg(doctest). It'd be nice to have it in not too far in the future.
rustdoc: Resolve module-level doc references more locally
Module level docs should resolve intra-doc links as locally as
possible. As such, this commit alters the heuristic for finding
intra-doc links such that we attempt to resolve names mentioned
in *inner* documentation comments within the (sub-)module rather
that from the context of its parent.
Signed-off-by: Daniel Silverstone <dsilvers@digital-scurf.org>
msizanoen [Tue, 22 Oct 2019 08:47:07 +0000 (15:47 +0700)]
Implement dual proc macro hashing
This changes the mechanism of `-Z dual-proc-macro` to record the host
proc macro hash in the transistive dependency information and use it
during dependency resolution instead of resolving only by name.
bors [Thu, 31 Oct 2019 02:20:30 +0000 (02:20 +0000)]
Auto merge of #65990 - Centril:rollup-v843h4a, r=Centril
Rollup of 7 pull requests
Successful merges:
- #65274 (Upload toolstates.json to rust-lang-ci2)
- #65434 (Add long error explanation for E0577)
- #65850 (Update comments re type parameter hack in object safety)
- #65955 (ci: revert msys2 ca-certificates hack)
- #65959 (Fix an incorrect docstring for Immediate in librustc_mir/interpret.)
- #65979 (Switch CrateMetadata's source_map_import_info from RwLock to Once)
- #65981 (work around aggressive syntax feature gating)
Rollup merge of #65981 - RalfJung:check-your-gates, r=Centril
work around aggressive syntax feature gating
This works around https://github.com/rust-lang/rust/issues/65860; fixing `rustc +nightly lib.rs --test --edition 2018` for libcore and thus unblocking https://github.com/RalfJung/miri-test-libstd.
Rollup merge of #65955 - pietroalbini:master-revert-msys2-hack, r=Mark-Simulacrum
ci: revert msys2 ca-certificates hack
The hack was added because upstream msys2 broke the ca-certificates package, but since then it has been fixed. This reverts CI to use the upstream package.
Rollup merge of #65850 - mikeyhew:patch-1, r=nikomatsakis
Update comments re type parameter hack in object safety
To check if a method's receiver type is object safe, we create a new receiver type by substituting in a bogus type parameter (let's call it `U`) for `Self`, and checking that the unmodified receiver type implements `DispatchFromDyn<receiver type with Self = U>`. It would be better to use `dyn Trait` directly, and the only reason we don't is because it triggers another check that `Trait` is object safe, resulting in a query cycle. Once the feature `object_safe_for_dispatch` (tracking issue https://github.com/rust-lang/rust/issues/43561) is stabilized, this will no longer be the case, and we'll be able to use `dyn Trait` as the unsized `Self` type. I've updated the comments in object_safety.rs accordingly.
Rollup merge of #65274 - pietroalbini:ci-upload-toolstate, r=alexcrichton
Upload toolstates.json to rust-lang-ci2
This PR does two things:
* Following up with https://github.com/rust-lang/rust/pull/65202, it migrates deploying artifacts to CI in a script. Both uploading release artifacts and CPU stats were merged into the same script, designing it to be easily extended.
* Uploads the toolstate JSON to `rust-lang-ci2` along with the release artifacts, both for Linux and Windows. This is needed because @RalfJung wants to stop shipping MIRI when its tests are failing, and the toolstate repo doesn't have entries for each commit. Having the toolstate data (just for that specific commit) on `rust-lang-ci2` will simplify the code a lot.
Most importantly it contains https://github.com/rust-lang/rls/commit/d267b49c2f7914f5b4bc94916dc56d64b37adf3a which fixes the RLS build whenever Clippy is built successfully in Rust CI.
Pietro Albini [Wed, 30 Oct 2019 18:41:22 +0000 (19:41 +0100)]
ci: move toolstates.json to /tmp/toolstate/ and docker mount it
Before this commit toolstates.json was stored in /tmp and it wasn't
mounted outside the build container. That caused uploading the file in
the upload-artifacts task to fail, as the file was missing on the host.
Mounting /tmp/toolstates.json alone is not the best approach: if the
file is missing when the container is started the Docker engine will
create a *directory* named /tmp/toolstates.json.
The Docker issue could be solved by pre-creating an empty file named
/tmp/toolstates.json, but doing that could cause problems if bootstrap
fails to generate the file and the toolstate scripts receive an empty
JSON.
The approach I took in this commit is to instead mount a /tmp/toolstate
directory inside Docker, and create the toolstates.json file in it. That
also required a small bootstrap change to ensure the directory is
created if it's missing.
Most importantly it contains https://github.com/rust-lang/rls/commit/d267b49c2f7914f5b4bc94916dc56d64b37adf3a
which fixes the RLS build whenever Clippy is built successfully in Rust CI.