Rollup merge of #48572 - alexcrichton:noexcept-msvc2, r=eddyb
rustc: Tweak funclet cleanups of ffi functions
This commit is targeted at addressing #48251 by specifically fixing a case where
a longjmp over Rust frames on MSVC runs cleanups, accidentally running the
"abort the program" cleanup as well. Added in #46833 `extern` ABI functions in
Rust will abort the process if Rust panics, and currently this is modeled as a
normal cleanup like all other destructors.
Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the
same mechanism used to implement panics in Rust. This means that `longjmp` over
Rust frames will run Rust cleanups (even though we don't necessarily want it
to). Notably this means that if you `longjmp` over a Rust stack frame then that
probably means you'll abort the program because one of the cleanups will abort
the process.
After some discussion on IRC it turns out that `longjmp` doesn't run cleanups
for *caught* exceptions, it only runs cleanups for cleanup pads. Using this
information this commit tweaks the codegen for an `extern` function to
a catch-all clause for exceptions instead of a cleanup block. This catch-all is
equivalent to the C++ code:
try {
foo();
} catch (...) {
bar();
}
and in fact our codegen here is designed to match exactly what clang emits for
that C++ code!
With this tweak a longjmp over Rust code will no longer abort the process. A
longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC.
Other non-MSVC platforms will not rust destructors with a longjmp, so we'll
probably still recommend "don't have destructors on the stack", but in any case
this is a more surgical fix than #48567 and should help us stick to standard
personality functions a bit longer.
Rollup merge of #48522 - etaoins:fix-find-width-of-character-at-span-bounds-check, r=estebank
Fix find_width_of_character_at_span bounds check
Commit 0bd96671f0 added bounds checking of our current target byte position to prevent infinite loops. Unfortunately it was comparing the file-relative `target` versus the global `file_start_pos` and `file_end_pos`.
The result is failing to detect multibyte characters unless their file-relative offset fit within their global offset. This causes other parts of the compiler to generate spans pointing to the middle of a
multibyte character which will ultimately panic in `bytepos_to_file_charpos`.
Fix by comparing the `target` to the total file size when moving forward and doing checked subtraction when moving backwards. This should preserve the intent of the bounds check while removing the offset confusion.
* Fixed rust-lang-nursery/rust-toolstate#1, a proper link to the PR will be included.
* Fixed rust-lang-nursery/rust-toolstate#2, a comment will be posted to the PR if the toolstate changed
* Toolstate regression will be rejected at the last week of the 6-week cycle (currently entirely date-based).
* Implemented https://internals.rust-lang.org/t/the-current-submodule-setup-is-not-tenable/6593, moved doc tests of Nomicon, Reference, Rust-by-Example and The Book to the "tools" job and thus allowed to fail like other external tools.
Niko Matsakis [Sun, 16 Jul 2017 17:32:34 +0000 (13:32 -0400)]
remove unnecessary clause propagating divergence
This should not be needed: the new variable will be related to the old
ones, so if they are constrained, so is the new variable; if they are
not, and hence default to diverging, so will the new variable.
bors [Thu, 1 Mar 2018 13:19:18 +0000 (13:19 +0000)]
Auto merge of #46785 - leodasvacas:type-check-defaults-at-declaration, r=nikomatsakis
[Underspecified semantics] Type check defaults at declaration.
Fixes #46669. See the test for code that compiles on stable but will no longer compile. This falls under a "Underspecified language semantics" fix. **Needs crater**.
On type and trait declarations, we currently allow anything that name checks as a type parameter default. That allows the user to write a default that can never be applied, or even a default that may conditionally be applied depending on the type of another parameter. Mostly this just defers the error to use sites, but also allows clever hacks such as `Foo<T, U = <T as Iterator>::Item>` where `U` will be able to apply it's default only when `T: Iterator`. Maybe that means this bug is a feature, but it's a fiddly behaviour that seems undesirable.
This PR validates defaults at declaration sites by ensuring all predicates on the parameter are valid for the default. With the exception of `Self: Sized` which we don't want to check to allow things like `trait Add<RHS = Self>`.
Alex Crichton [Tue, 27 Feb 2018 02:59:47 +0000 (18:59 -0800)]
rustc: Tweak funclet cleanups of ffi functions
This commit is targeted at addressing #48251 by specifically fixing a case where
a longjmp over Rust frames on MSVC runs cleanups, accidentally running the
"abort the program" cleanup as well. Added in #46833 `extern` ABI functions in
Rust will abort the process if Rust panics, and currently this is modeled as a
normal cleanup like all other destructors.
Unfortunately it turns out that `longjmp` on MSVC is implemented with SEH, the
same mechanism used to implement panics in Rust. This means that `longjmp` over
Rust frames will run Rust cleanups (even though we don't necessarily want it
to). Notably this means that if you `longjmp` over a Rust stack frame then that
probably means you'll abort the program because one of the cleanups will abort
the process.
After some discussion on IRC it turns out that `longjmp` doesn't run cleanups
for *caught* exceptions, it only runs cleanups for cleanup pads. Using this
information this commit tweaks the codegen for an `extern` function to
a catch-all clause for exceptions instead of a cleanup block. This catch-all is
equivalent to the C++ code:
try {
foo();
} catch (...) {
bar();
}
and in fact our codegen here is designed to match exactly what clang emits for
that C++ code!
With this tweak a longjmp over Rust code will no longer abort the process. A
longjmp will continue to "accidentally" run Rust cleanups (destructors) on MSVC.
Other non-MSVC platforms will not rust destructors with a longjmp, so we'll
probably still recommend "don't have destructors on the stack", but in any case
this is a more surgical fix than #48567 and should help us stick to standard
personality functions a bit longer.
leonardo.yvens [Sun, 21 Jan 2018 14:09:06 +0000 (12:09 -0200)]
Check WF of predicate with defaults only if all in LHS have default
Given a trait predicate, if all params appearing in the LHS have
defaults then it should be a backwards compatible predicate. We verify
that by checking the WF of predicate with all defaults substituted
simultaneously.
kennytm [Wed, 28 Feb 2018 11:15:39 +0000 (19:15 +0800)]
Rollup merge of #48541 - varkor:inlined-main, r=michaelwoerister
Ensure main() always has external linkage
This ensures that the entry function is never elided due to inlining, even with `inline(always)`. Fixes #47783.
There were a couple of possible ways of addressing this issue; I simply picked the one that seemed most direct. A warning could be appropriate, but considering using inlining hints in other places it doesn't apply also throws no warnings, and it seems like an edge case anyway, I haven't added one for now.
kennytm [Wed, 28 Feb 2018 11:15:38 +0000 (19:15 +0800)]
Rollup merge of #48497 - scottmcm:more-restricted-termination, r=nikomatsakis
Restrict the Termination impls to simplify stabilization
Make a minimal commitment in preparation for stabilization. More impls, or broader ones, are likely in future, but are not necessary at this time and are more controversial.
cc https://github.com/rust-lang/rust/issues/48453#issuecomment-368155082
r? @nikomatsakis
kennytm [Wed, 28 Feb 2018 11:15:36 +0000 (19:15 +0800)]
Rollup merge of #48488 - varkor:handle-gdb-error-compiletest, r=michaelwoerister
Handle gdb command failure gracefully in compiletest
Previously, if the gdb command was available, but threw an error, compiletest would panic. This is obviously not good. Now, gdb is treated as missing if calling `gdb --version` does not output anything on stdout.
kennytm [Wed, 28 Feb 2018 11:15:35 +0000 (19:15 +0800)]
Rollup merge of #48484 - glaubitz:powerpcspe-linux, r=alexcrichton
Add support for powerpc-unknown-linux-gnuspe
This PR adds support for the embedded PowerPC variant "e500". On Linux, this architecture is usually called "powerpcspe", it is a 32-bit PowerPC architecture. The main difference between normal 32-bit PowerPC and PowerPCSPE is the lack of Altivec instructions and the additional SPE instruction set.
This architecture is supported in Debian through an unofficial port.
kennytm [Wed, 28 Feb 2018 11:15:28 +0000 (19:15 +0800)]
Rollup merge of #48321 - milesand:no_panic_pow, r=alexcrichton
Add non-panicking variants of pow for integer types
Currently, calling pow may panic in case of overflow, and the function does not have non-panicking counterparts. Thus, it would be beneficial to add those in.
kennytm [Wed, 28 Feb 2018 11:15:27 +0000 (19:15 +0800)]
Rollup merge of #48266 - pietroalbini:report-compiler-flags-on-ice, r=michaelwoerister
Report non-standard compile flags on ICE
Some ICEs (such as the recent #48248) only happens when a non-standard compiler flag is provided to rustc, but users don't always report the used flags. This can slow down reproducing the issue, so this PR shows all the non-standard compiler flags in the ICE error message.
For example, the output of #48248 with this PR is:
```
error: internal compiler error: [...]
thread 'rustc' panicked at [...]
note: Run with `RUST_BACKTRACE=1` for a backtrace.
note: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report: [...]
note: rustc 1.25.0-dev running on x86_64-unknown-linux-gnu
note: compiler flags: -C link-dead-code
```
### Open questions
* At the moment, only `-C` and `-Z` flags are shown by default, and all the ones provided by cargo in a standard build are ignored: I did this to only show the flags that probably caused the ICE, and to remove some noise from the message. This removed flags like `opt-level` and `debuginfo` though, could those be useful for reproducing ICEs?
bors [Wed, 28 Feb 2018 07:10:05 +0000 (07:10 +0000)]
Auto merge of #48056 - ExpHP:macro-commas, r=dtolnay
Comprehensively support trailing commas in std/core macros
I carefully organized the changes into four commits:
* Test cases
* Fixes for `macro_rules!` macros
* Fixes for builtin macros
* Docs for builtins
**I can easily scale this back to just the first two commits for now if such is desired.**
### Breaking (?) changes
* This fixes #48042, which is a breaking change that I hope people can agree is just a bugfix for an extremely dark corner case.
* To fix five of the builtins, this changes `syntax::ext::base::get_single_str_from_tts` to accept a trailing comma, and revises the documentation so that this aspect is not surprising. **I made this change under the (hopefully correct) understanding that `libsyntax` is private rustc implementation detail.** After reviewing all call sites (which were, you guessed it, *precisely those five macros*), I believe the revised semantics are closer to the intended spirit of the function.
### Changes which may require concensus
Up until now, it could be argued that some or all the following macros did not conceptually take a comma-separated list, because they only took one argument:
* **`cfg(unix,)`** (most notable since cfg! is unique in taking a meta tag)
* **`include{,_bytes,_str}("file.rs",)`** (in item form this might be written as "`include!{"file.rs",}`" which is even slightly more odd)
* **`compile_error("message",);`**
* **`option_env!("PATH",)`**
* **`try!(Ok(()),)`**
So I think these particular changes may require some sort of consensus. **All of the fixes for builtins are included this list, so if we want to defer these decisions to later then I can scale this PR back to just the first two commits.**
### Other notes/general requests for comment
* Do we have a big checklist somewhere of "things to do when adding macros?" My hope is for `run-pass/macro-comma-support.rs` to remain comprehensive.
* Originally I wanted the tests to also comprehensively forbid double trailing commas. However, this didn't work out too well: [see this gist and the giant FIXME in it](https://gist.github.com/ExpHP/6fc40e82f3d73267c4e590a9a94966f1#file-compile-fail_macro-comma-support-rs-L33-L50)
* I did not touch `select!`. It appears to me to be a complete mess, and its trailing comma mishaps are only the tip of the iceberg.
* There are [some compile-fail test cases](https://github.com/ExpHP/rust/blob/5fa97c35da2f0ee/src/test/compile-fail/macro-comma-behavior.rs#L49-L52) that didn't seem to work (rustc emits errors, but compile-fail doesn't acknowledge them), so they are disabled. Any clues? (Possibly related: These happen to be precisely the set of errors which are tagged by rustc as "this error originates in a macro outside of the current crate".)
bors [Wed, 28 Feb 2018 04:24:18 +0000 (04:24 +0000)]
Auto merge of #47894 - vi:rustdoc_foldable_impls, r=GuillaumeGomez,QuietMisdreavus
rustdoc: Foldable impl blocks
Addresses #40363, #45720, #24483, #23986 and so on
* Expands and refactors collapseDocs and toggleAllDocs
* Adds [-] toggle to all impls (including inherent impl)
* Makes it hiding though main css file, not though element inline style
May need to be addressed:
* "[-]" and anchor link copier are overlaid a bit
* Inherent methods are also hidden by the global [-] toggle.
* Auto-collapsing "Iterator" and so on by default is not implemented yet
* Tested only shallowly and only in Chromiuim
* No tests. Are there tests for css/js part here?
* The new implementation may be a bit slower.
What next steps are need to be done before the integration?
bors [Tue, 27 Feb 2018 00:29:50 +0000 (00:29 +0000)]
Auto merge of #48449 - petrochenkov:uidiff, r=nikomatsakis
Anonymize some line numbers in UI test output
New unstable flag `-Z ui-testing` is introduced. This flag changes diagnostic output of the compiler *in some way* making it more suitable for UI testing (this is intentionally vague).
At the moment this flag anonymizes line numbers at line starts thus solving the largest issue with UI test diffs. If diffs continue to be too noisy, some other tweaks could be applied (e.g. anonymizing lines/columns in `--> $DIR/file.rs:line:column`), but this needs some time and experience (we shouldn't diverge too much from the actual output in general).
If comment `// disable-ui-testing-normalization` is added to an UI test, then `-Z ui-testing` is not passed.
projects / rust.git / log