bors [Fri, 15 Feb 2019 12:15:17 +0000 (12:15 +0000)]
Auto merge of #58403 - eddyb:requalify, r=oli-obk
rustc_mir: split qualify_consts' "value qualification" bitflags into separate computations.
Prerequisite for computing those bits through a dataflow algorithm ~~(which I might do in this PR later)~~.
This PR should not change behavior overall, other than treating `simd_shuffle*` identically to `#[rustc_args_required_const]` (maybe we should just have `#[rustc_args_required_const]` on the intrinsic imports of `simd_shuffle*`? cc @gnzlbg)
bors [Thu, 14 Feb 2019 10:32:25 +0000 (10:32 +0000)]
Auto merge of #58455 - Centril:rollup, r=Centril
Rollup of 7 pull requests
Successful merges:
- #58309 (Add more profiler events)
- #58347 (Closure bounds fixes)
- #58365 (Add an option to print the status of incremental tasks / dep nodes after running them)
- #58371 (Check user type annotations for range patterns.)
- #58378 (rustc: Implement incremental "fat" LTO)
- #58407 (specify "upper camel case" in style lint)
- #58449 (Notify @topecongiro when the state of rustfmt has changed)
Rollup merge of #58378 - alexcrichton:incremental-lto, r=michaelwoerister
rustc: Implement incremental "fat" LTO
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
Rollup merge of #58371 - davidtwco:issue-58299, r=arielb1
Check user type annotations for range patterns.
Fixes #58299.
This PR builds on the fix from #58161 (which fixed miscompilation
caused by the introduction of `AscribeUserType` patterns for associated
constants) to start checking these patterns are well-formed for ranges
(previous fix just ignored them so that miscompilation wouldn't occur).
Rollup merge of #58347 - matthewjasper:closure-bounds-fixes, r=pnkfelix
Closure bounds fixes
* Ensures that "nice region errors" are buffered so that they are sorted and migrated correctly.
* Propagates fewer constraints for closures (cc #58178)
* Propagate constraints from closures more precisely (#58127)
bors [Thu, 14 Feb 2019 04:22:35 +0000 (04:22 +0000)]
Auto merge of #58446 - Centril:rollup, r=Centril
Rollup of 8 pull requests
Successful merges:
- #57451 (suggestion-diagnostics: as_ref improve snippet)
- #57856 (Convert old first edition links to current edition one)
- #57992 (Update the future/task API)
- #58258 (Reduce the size of `hir::Expr`.)
- #58267 (Tweak "incompatible match arms" error)
- #58296 (Hidden suggestion support)
- #58301 (Enable comparing fat pointers)
- #58308 (Extract block to insert an intrinsic into its own function)
Rollup merge of #58267 - estebank:match-arms, r=matthewjasper
Tweak "incompatible match arms" error
- Point at the body expression of the match arm with the type error.
- Point at the prior match arms explicitly stating the evaluated type.
- Point at the entire match expr in a secondary span, instead of primary.
- For type errors in the first match arm, the cause is outside of the
match, treat as implicit block error to give a more appropriate error.
Rollup merge of #58420 - dvdhrm:target-uefi-comments, r=nagisa
target/uefi: clarify documentation
This clarifies why FP-units are disabled on UEFI targets, as well as
why we must opt into the NXCOMPAT feature.
I did find some time to investigate why GRUB and friends disable FP on
UEFI. The specification explicitly allows using MMX/SSE/AVX, but as it
turns out it does not mandate enabling the instruction sets explicitly.
Hence, any use of these instructions will trigger CPU exceptions,
unless an application explicitly enables them (which is not an option,
as these are global flags that better be controlled by the
kernel/firmware).
Furthermore, UEFI systems are allowed to mark any non-code page as
non-executable. Hence, we must make sure to never place code on the
stack or heap. So we better pass /NXCOMPAT to the linker for it to
complain if it ever places code in non-code pages.
Lastly, this fixes some typos in related comments.
Rollup merge of #58381 - davidtwco:issue-42944, r=estebank
Only suggest imports if not imported.
Fixes #42944 and fixes #53430.
This commit modifies name resolution error reporting so that if a name
is in scope and has been imported then we do not suggest importing it.
This can occur when we add a label about constructors not being visible
due to private fields. In these cases, we know that the struct/variant
has been imported and we should silence any suggestions to import the
struct/variant.
Rollup merge of #58202 - varkor:deprecated-future-external, r=GuillaumeGomez
Ignore future deprecations in #[deprecated]
The future deprecation warnings should only apply to `#[rustc_deprecated]` as they take into account rustc's version. Fixes #57952.
I've also slightly modified rustdoc's display of future deprecation notices to make it more consistent, so I'm assigning a rustdoc team member for review to make sure this is okay.
David Rheinsberg [Wed, 13 Feb 2019 10:50:09 +0000 (11:50 +0100)]
target/uefi: clarify documentation
This clarifies why FP-units are disabled on UEFI targets, as well as
why we must opt into the NXCOMPAT feature.
I did find some time to investigate why GRUB and friends disable FP on
UEFI. The specification explicitly allows using MMX/SSE/AVX, but as it
turns out it does not mandate enabling the instruction sets explicitly.
Hence, any use of these instructions will trigger CPU exceptions,
unless an application explicitly enables them (which is not an option,
as these are global flags that better be controlled by the
kernel/firmware).
Furthermore, UEFI systems are allowed to mark any non-code page as
non-executable. Hence, we must make sure to never place code on the
stack or heap. So we better pass /NXCOMPAT to the linker for it to
complain if it ever places code in non-code pages.
Lastly, this fixes some typos in related comments.
bors [Wed, 13 Feb 2019 10:27:50 +0000 (10:27 +0000)]
Auto merge of #58238 - Mark-Simulacrum:doctest-fix, r=alexcrichton
Fixes rustdoc in stage 0, stage 1
When a request for rustdoc is passed for stage 0, x.py build --stage 0
src/tools/rustdoc or ensure(tool::Rustdoc { .. }) with top_stage = 0, we
return the rustdoc for that compiler (i.e., the beta rustdoc).
This fixes stage 0 of https://github.com/rust-lang/rust/issues/52186 as well as being part of general workflow improvements (making stage 0 testing for std work) for rustbuild.
The stage 1 fix (second commit) completely resolves the problem, so this fixes https://github.com/rust-lang/rust/issues/52186.
bors [Wed, 13 Feb 2019 07:46:21 +0000 (07:46 +0000)]
Auto merge of #58235 - jethrogb:jb/sgx-usercall-internals, r=alexcrichton
SGX target: simplify usercall internals
This moves logic from assembly to Rust and removes the special case for exit/panic handling, merging it with regular usercall handling.
Also, this fixes a bug in the exit usercall introduced in a75ae00. The bug would make regular exits look like panics with high probability. It would also with some probability leak information through uncleared registers.
Rollup merge of #58404 - euclio:cloudabi-keyserver, r=alexcrichton
use Ubuntu keyserver for CloudABI ports
The Ubuntu keyserver is more reliable than the MIT PGP server, which is
prone to going down. This commit also explicitly uses port 80 on the
keyserver for reasons outlined in #57844.
Rollup merge of #58289 - haraldh:master, r=sfackler
impl iter() for dyn Error
Examples:
```rust
let next_error_type_a = err
.iter()
.filter_map(Error::downcast_ref::<ErrorTypeA>)
.next();
```
```rust
let source_root_error = err.iter().last();
```
Credit for the ErrorIter goes to reddit user /u/tdiekmann (Tim Diekmann)
https://www.reddit.com/r/rust/comments/aj3lpg/is_an_iterator_impl_over_errorsource_possible/
Rollup merge of #58200 - RalfJung:str-as-mut-ptr, r=SimonSapin
fix str mutating through a ptr derived from &self
Found by Miri: In `get_unchecked_mut` (also used by the checked variants internally) uses `str::as_ptr` to create a mutable reference, but `as_ptr` takes `&self`. This means the mutable references we return here got created from a shared reference, which violates the shared-references-are-read-only discipline!
For this by using a newly introduced `as_mut_ptr` instead.
Rollup merge of #58057 - michaelwoerister:stabilize-xlto, r=alexcrichton
Stabilize linker-plugin based LTO (aka cross-language LTO)
This PR stabilizes [linker plugin based LTO](https://github.com/rust-lang/rust/issues/49879), also known as "cross-language LTO" because it allows for doing inlining and other optimizations across language boundaries in mixed Rust/C/C++ projects.
As described in the tracking issue, it works by making `rustc` emit LLVM bitcode instead of machine code, the same as `clang` does. A linker with the proper plugin (like LLD) can then run (Thin)LTO across all modules.
The feature has been implemented over a number of pull requests and there are various [codegen](https://github.com/rust-lang/rust/blob/master/src/test/codegen/no-dllimport-w-cross-lang-lto.rs) and [run](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-clang)-[make](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs) [tests](https://github.com/rust-lang/rust/tree/master/src/test/run-make-fulldeps/cross-lang-lto) that make sure that it keeps working.
The PR makes the feature available under the `-C linker-plugin-lto` flag. As discussed in the tracking issue it is not cross-language specific and also not LLD specific. `-C linker-plugin-lto` is descriptive of what it does. If someone has a better name, let me know `:)`
Rollup merge of #57815 - dotdash:asserts, r=sfackler
Speed up the fast path for assert_eq! and assert_ne!
Currently, the panic!() calls directly borrow the value bindings. This
causes those bindings to always be initialized, i.e. they're initialized
even before the values are even compared. This causes noticeable
overhead in what should be a really cheap operation.
By performing a reborrow of the value in the call to panic!(), we allow
LLVM to optimize that code, so that the extra borrow only happens in the
error case.
We could achieve the same result by dereferencing the values passed to
panic!(), as the format machinery borrows them anyway, but this causes
assertions to fail to compile if one of the values is unsized, i.e. it
would be a breaking change.
bors [Tue, 12 Feb 2019 19:09:24 +0000 (19:09 +0000)]
Auto merge of #58341 - alexreg:cosmetic-2-doc-comments, r=steveklabnik
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
David Wood [Mon, 11 Feb 2019 11:18:40 +0000 (12:18 +0100)]
Check user type annotations for range patterns.
This commit builds on the fix from #58161 (which fixed miscompilation
caused by the introduction of `AscribeUserType` patterns for associated
constants) to start checking these patterns are well-formed for ranges
(previous fix just ignored them so that miscompilation wouldn't occur).
Andy Russell [Tue, 12 Feb 2019 04:50:31 +0000 (23:50 -0500)]
use Ubuntu keyserver for CloudABI ports
The Ubuntu keyserver is more reliable than the MIT PGP server, which is
prone to going down. This commit also explicitly uses port 80 on the
keyserver for reasons outlined in #57844.
Alex Crichton [Mon, 11 Feb 2019 15:46:04 +0000 (07:46 -0800)]
rustc: Implement incremental "fat" LTO
Currently the compiler will produce an error if both incremental
compilation and full fat LTO is requested. With recent changes and the
advent of incremental ThinLTO, however, all the hard work is already
done for us and it's actually not too bad to remove this error!
This commit updates the codegen backend to allow incremental full fat
LTO. The semantics are that the input modules to LTO are all produce
incrementally, but the final LTO step is always done unconditionally
regardless of whether the inputs changed or not. The only real
incremental win we could have here is if zero of the input modules
changed, but that's so rare it's unlikely to be worthwhile to implement
such a code path.
projects / rust.git / log