bors [Wed, 6 Nov 2019 02:29:21 +0000 (02:29 +0000)]
Auto merge of #66141 - Centril:rollup-n2fcvp9, r=Centril
Rollup of 11 pull requests
Successful merges:
- #65892 (Remove `PartialEq` and `Eq` from the `SpecialDerives`.)
- #66014 (Show type parameter name and definition in type mismatch error messages )
- #66027 (Move has_panic_handler to query)
- #66054 (syntax: Avoid span arithmetic for delimiter tokens)
- #66068 (use silent emitter for rustdoc highlighting pass)
- #66081 (let caller of check_ptr_access_align control the error message)
- #66093 (Do not ICE with a precision flag in formatting str and no format arguments)
- #66098 (Detect `::` -> `:` typo when involving turbofish)
- #66101 (Tweak type mismatch caused by break on tail expr)
- #66106 (Fix typo in explanation of `E0080`)
- #66115 (rustc: remove "GlobalMetaData" dead code from hir::map::definitions.)
Rollup merge of #66101 - estebank:break-tail-e0308, r=Centril
Tweak type mismatch caused by break on tail expr
When `break;` has a type mismatch because the `Destination` points at a tail
expression with an obligation flowing from a return type, point at the
return type.
Rollup merge of #66054 - petrochenkov:delspan, r=estebank
syntax: Avoid span arithmetic for delimiter tokens
The +/-1 logic is from the time where the whole group had a single span and the delimiter spans had to be calculated from it.
Now the delimiters have their own spans which are constructed by lexer or proc macro API and can be used directly.
If those spans are not perfect, then it should be fixed by tweaking the corresponding lexer logic rather than by trying to add or substract `1` from the span boundaries.
Rollup merge of #66027 - Mark-Simulacrum:panic-handler-query, r=alexcrichton
Move has_panic_handler to query
Moves us off of a global Once instead re-querying the lang item each time. The conditions on when we set it to true change a little (previously we'd make sure a few more lang items were `Some`) but I think they in practice don't matter, we won't compile later on if we don't have them.
Esteban Küber [Tue, 5 Nov 2019 02:47:02 +0000 (18:47 -0800)]
Tweak type mismatch caused by break on tail expr
When `break;` has a type mismatch because the `Destination` points at a tail
expression with an obligation flowing from a return type, point at the
return type.
Pietro Albini [Tue, 5 Nov 2019 13:37:07 +0000 (14:37 +0100)]
Rollup merge of #66082 - GuillaumeGomez:cleanup-highlightsourcelines, r=kinnison
clean highlightSourceLines code
This is the first part of https://github.com/rust-lang/rust/issues/66046. Now that I've splitted the hashchange stuff and the source code lines highlighting, I'll be able to fix the whole issue once and for all.
The `#[rustc_args_required_const]` attribute was added to `simd_shuffle*` in rust-lang/stdarch#825. This caused `promote_consts` to double-count its second argument when recording promotion candidates, which caused the promotion candidate compatibility check to fail.
Once `stdarch` is updated in-tree to include rust-lang/stdarch#825, all special logic around `simd_shuffle` can and should be removed.
Pietro Albini [Tue, 5 Nov 2019 13:36:55 +0000 (14:36 +0100)]
Rollup merge of #65948 - danielhenrymantilla:doc/maybe_uninit_ref_mut, r=RalfJung
Improve MaybeUninit::get_{ref,mut} documentation
As mentioned in https://github.com/rust-lang/rust/issues/63568#issuecomment-544106668, `MaybeUninit`'s `get_{ref,mut}` documentation is lacking, so this PR attempts to fix that.
That being said, and as @RalfJung mentions in that thread,
> In particular, we should clarify that all the UB rules for these methods equally apply when calling the raw ptr methods and creating a reference manually.
these other docs also need to be improved, which I can do in this PR ~~(hence the `[WIP]`)~~.
Finally, since all these documentations are related to clearly establishing when dealing with uninitialized memory which patterns are known to be sound and which patterns are currently UB (that is, until, if ever, the rules around references to unintialized integers get relaxed, this documentation will treat them as UB, and advise against such patterns (_e.g._, it is not possible to use uninitialized buffers with the `Read` API)), I think that adding even more examples to the main documentation of `MaybeUninit` inherent definition wouldn't hurt either.
bors [Tue, 5 Nov 2019 09:31:36 +0000 (09:31 +0000)]
Auto merge of #66109 - pietroalbini:rollup-2npidna, r=pietroalbini
Rollup of 10 pull requests
Successful merges:
- #65136 (Update codegen option documentation.)
- #65574 (docs: improve disclaimer regarding LinkedList)
- #65720 (Add FFI bindings for LLVM's Module::getInstructionCount())
- #65905 ([doc] fixes for unix/vxworks `OpenOptionsExt::mode`)
- #65962 (Fix logic in example.)
- #66019 (Improved std::iter::Chain documentation)
- #66038 (doc(str): show example of chars().count() under len())
- #66042 (Suggest correct code when encountering an incorrect trait bound referencing the current trait)
- #66073 (Do not needlessly write-lock)
- #66096 (Add a failing UI test for multiple loops of all kinds in a `const`)
Pietro Albini [Tue, 5 Nov 2019 08:50:00 +0000 (09:50 +0100)]
Rollup merge of #66096 - ecstatic-morse:const-loop-test, r=Centril
Add a failing UI test for multiple loops of all kinds in a `const`
This simply demonstrates the current behavior and ensures we don't allow anything by accident.
The new const checker will be able to improve the diagnostics here. While working on it, I didn't see very many tests with non-`while` loops in a `const`, and there were no tests with multiple loops.
I wasn't sure which of the syntax versions is better (`<Self as ..>::` vs `Self::`), so I used the former simply because it was less change to the existing code.
Pietro Albini [Tue, 5 Nov 2019 08:49:50 +0000 (09:49 +0100)]
Rollup merge of #65720 - icefoxen:LLVMgetInstructionCount, r=rkruppe
Add FFI bindings for LLVM's Module::getInstructionCount()
Just to make it usable for profiling and such inside
rustc itself. It was vaguely useful in
https://wiki.alopex.li/WhereRustcSpendsItsTime and I figured
I might as well upstream it; I may or may not ever get around
to doing more with it (hopefully I will), but it may be useful
for others.
Pietro Albini [Tue, 5 Nov 2019 08:49:47 +0000 (09:49 +0100)]
Rollup merge of #65136 - ehuss:update-codegen-options, r=Dylan-DPC
Update codegen option documentation.
Some documentation updates:
- Add more detail to codegen options.
- Add missing options:
- `force-frame-pointers`
- `default-linker-libraries`
- `linker-plugin-lto`
- Add fragment anchors for all command-line-arguments.
- Add some cross links between options.
bors [Tue, 5 Nov 2019 05:47:31 +0000 (05:47 +0000)]
Auto merge of #65938 - eddyb:fn-abi-rename, r=oli-obk
rustc_target: rename {Fn,Arg}Type to {Fn,Arg}Abi.
I was trying to tweak the API of `FnType` (now `FnAbi`) and the name kept bothering me.
`FnAbi` is to a function signature a bit like a layout is to a type, so the name still isn't perfect yet, but at least it doesn't have the misleading `Type` in it anymore.
If this can't land I think I can continue my original refactor without it, so I'm not strongly attached to it.
bors [Mon, 4 Nov 2019 21:06:50 +0000 (21:06 +0000)]
Auto merge of #65874 - Nadrieril:clarify-usefulness, r=varkor
Clarify pattern-matching usefulness algorithm
This PR clarifies a bit the usefulness algorithm by emphasizing that each row of the matrix can be seen as a sort of stack from which we pop constructors. It also moves code around to increase separation of concerns.
This is part of my splitting of https://github.com/rust-lang/rust/pull/65160 into smaller PRs.
bors [Mon, 4 Nov 2019 12:16:00 +0000 (12:16 +0000)]
Auto merge of #66078 - petrochenkov:gateout, r=Centril
expand: Feature gate out-of-line modules in proc macro input
Extracted from https://github.com/rust-lang/rust/pull/64273.
We are currently gating attributes applied directly to `mod` items because there are unresolved questions about out-of-line modules and their behavior is very likely to change.
However, you can sneak an out-of-line module into an attribute macro input using modules nested into other items like
```rust
#[my_attr]
fn m() {
#[path = "zzz.rs"]
mod n; // what tokens does the `my_attr` macro see?
}
```
This PR prevents that and emits a feature gate error for this case as well.
r? @Centril
It would be great to land this before beta.
bors [Mon, 4 Nov 2019 09:00:39 +0000 (09:00 +0000)]
Auto merge of #65835 - Mark-Simulacrum:lockless-lintbuffer, r=nikomatsakis
Remove LintBuffer from Session
This moves the `LintBuffer` from `Session` into the `Resolver`, where it is used until lowering is done and then consumed by early lint passes. This also happily removes the failure mode of buffering lints too late where it would have previously lead to ICEs; it is statically no longer possible to do so.
I suspect that with a bit more work a similar move could be done for the lint buffer inside `ParseSess`, but this PR doesn't touch it (in part to keep itself small).
The last commit is the "interesting" commit -- the ones before it don't work (though they compile) as they sort of prepare the various crates for the lint buffer to be passed in rather than accessed through Session.
bors [Mon, 4 Nov 2019 02:30:45 +0000 (02:30 +0000)]
Auto merge of #65838 - estebank:resilient-recovery, r=Centril
Reduce amount of errors given unclosed delimiter
When in a file with a non-terminated item, catch the error and consume
the block instead of trying to recover it on a more granular way in order to
reduce the amount of unrelated errors that would be fixed after adding
the missing closing brace. Also point out the possible location of the
missing closing brace.
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)
The proper attribute was added to `simd_shuffle*` in
rust-lang/stdarch#825. This caused `promote_consts` to double-count its
second argument when recording promotion candidates, which caused
the promotion candidate compatibility check to fail.