bors [Mon, 18 Feb 2019 08:37:18 +0000 (08:37 +0000)]
Auto merge of #58541 - kennytm:fix-publish-toolstate-py-again, r=oli-obk
publish_toolstate.py: further fix the runtime errors
The regex was missing a `,`, causing `relevant_pr_match` to become None and set the PR number to -1 and assigned the new issue to `@<unknown user>`. This causes the 422 error when creating the issue due to invalid assignee and unable to leave the tool-is-broken comment since PR -1 does not exist.
The default user names are now also changed to @ghost to prevent the 422 error in case anything goes wrong again.
kennytm [Sun, 17 Feb 2019 15:19:47 +0000 (23:19 +0800)]
publish_toolstate.py: further fix the runtime errors
The regex was missing a `,`, causing `relevant_pr_match` to become None
and set the PR number to -1 and assigned the new issue to
`@<unknown user>`. This causes the 422 error when creating the issue due
to invalid assignee and unable to leave the tool-is-broken comment since
PR -1 does not exist.
The default user names are now also changed to @ghost to prevent the
422 error in case anything goes wrong again.
bors [Sun, 17 Feb 2019 14:29:33 +0000 (14:29 +0000)]
Auto merge of #58416 - cuviper:dist-linux-gcc, r=alexcrichton
[CI] Update GCC in the dist-linux builders
Upstream LLVM is planning to raise their minimum toolchain requirements, so they may start using C++14 features. This new policy has already landed in the form of a "soft" error.
http://lists.llvm.org/pipermail/llvm-dev/2019-February/130117.html
For GCC, they will require at least version 5.1. This PR moves our crosstool-ng builders to their max GCC 5.2, with a few small patches to fix compatibility. The dist-x86_64-linux builder is updated to GCC 5.5 and LLVM/Clang 8.0.0-rc2, which also affects dist-i686-linux sharing the same scripts.
kennytm [Fri, 15 Feb 2019 16:56:00 +0000 (00:56 +0800)]
Rollup merge of #58468 - RalfJung:maybe-uninit-split, r=Centril
split MaybeUninit into several features, expand docs a bit
This splits the `maybe_uninit` feature gate into several:
* `maybe_uninit` for what we will hopefully stabilize soon-ish.
* `maybe_uninit_ref` for creating references into `MaybeUninit`, for which the rules are not yet clear.
* `maybe_uninit_slice` for handling slices of `MaybeUninit`, which needs more API design work.
* `maybe_uninit_array` for creating arrays of `MaybeUninit` using a macro (because we don't have https://github.com/rust-lang/rust/issues/49147 yet).
Is that an okay thing to do? The goal is to help people avoid APIs we do not want to stabilize yet. I used this to make sure rustc itself does not use `get_ref` and `get_mut`.
I also extended the docs to advise against uninitialized integers -- again this is something for which the rules are still being discussed.
kennytm [Fri, 15 Feb 2019 16:55:59 +0000 (00:55 +0800)]
Rollup merge of #58448 - euclio:missing-summaries, r=QuietMisdreavus
rustdoc: mask `compiler_builtins` docs
Fixes #46783.
I wasn't able to fully confirm the underlying cause, but my theory is that functions in `compiler_builtins` were overwriting functions with the same names in libcore in the search index. Since the functions in `compiler_builtins` didn't have docs, that's why they weren't appearing in the results.
Masking the `compiler_builtins` crate fixes the search results. It appears that this crate was accidentally unmasked in #49503.
kennytm [Fri, 15 Feb 2019 16:55:56 +0000 (00:55 +0800)]
Rollup merge of #58438 - cuviper:posix_spawn_file_actions_addchdir_np, r=alexcrichton
Use posix_spawn_file_actions_addchdir_np when possible
This is a non-POSIX extension implemented in Solaris and in glibc 2.29.
With this we can still use `posix_spawn()` when `Command::current_dir()`
has been set, otherwise we fallback to `fork(); chdir(); exec()`.
kennytm [Fri, 15 Feb 2019 16:55:54 +0000 (00:55 +0800)]
Rollup merge of #58429 - RalfJung:box, r=TimNN
fix Box::into_unique effecitvely transmuting to a raw ptr
Miri/Stacked Borrows treat `Box` specially: they assert that it is unique, and tag it appropriately. However, currently, `Box::into_inner` is not aware of that and returns a raw pointer (wrapped in a `Unique`) that carries the same tag as the box, meaning it carries a `Uniq` tag. This leads to all sorts of problems when people use the raw pointer they get out of the `Unique` type.
In the future, it'd be interesting to make `Unique` also carry some kind of uniqueness. In that case, something like this would instead be needed whenever a raw pointer is extracted from a `Unique`. However, that is out-of-scope for the current version of Stacked Borrows. So until then, this changes `into_unique` to perform a proper reference-to-raw-ptr-cast, which clears the tag.
kennytm [Fri, 15 Feb 2019 16:55:49 +0000 (00:55 +0800)]
Rollup merge of #58196 - varkor:const-fn-feature-gate-error, r=oli-obk
Add specific feature gate error for const-unstable features
Before:
```
error: `impl Trait` in const fn is unstable
--> src/lib.rs:7:19
|
7 | const fn foo() -> impl T {
| ^^^^^^
error: aborting due to previous error
```
After:
```
error[E0723]: `impl Trait` in const fn is unstable (see issue #57563)
--> src/lib.rs:7:19
|
7 | const fn foo() -> impl T {
| ^^^^^^
= help: add #![feature(const_fn)] to the crate attributes to enable
error: aborting due to previous error
```
This improves the situation with https://github.com/rust-lang/rust/issues/57563. Fixes https://github.com/rust-lang/rust/issues/57544. Fixes https://github.com/rust-lang/rust/issues/54469.
kennytm [Fri, 15 Feb 2019 16:55:47 +0000 (00:55 +0800)]
Rollup merge of #58074 - scottmcm:stabilize-sort_by_cached_key, r=SimonSapin
Stabilize slice_sort_by_cached_key
I was going to ask on the tracking issue (https://github.com/rust-lang/rust/issues/34447), but decided to just send this and hope for an FCP here. The method was added last March by https://github.com/rust-lang/rust/pull/48639.
That's an identical signature to the existing `sort_by_key`, so I think the questions are just naming, implementation, and the usual "do we want this?".
The implementation seems to have proven its use in rustc at least, which many uses: https://github.com/rust-lang/rust/search?l=Rust&q=sort_by_cached_key
(I'm asking because it's exactly what I just needed the other day:
```rust
all_positions.sort_by_cached_key(|&n|
data::CITIES.iter()
.map(|x| *metric_closure.get_edge(n, x.pos).unwrap())
.sum::<usize>()
);
```
since caching that key is a pretty obviously good idea.)
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.
Andy Russell [Thu, 14 Feb 2019 00:57:12 +0000 (19:57 -0500)]
mask `compiler_builtins` docs
Since `compiler_builtins` is being injected automatically, its docs
aren't masked. This commit masks the crate's docs if it's brought in as
an extern crate.
Josh Stone [Wed, 13 Feb 2019 20:20:23 +0000 (12:20 -0800)]
Use posix_spawn_file_actions_addchdir_np when possible
This is a non-POSIX extension implemented in Solaris and in glibc 2.29.
With this we can still use `posix_spawn()` when `Command::current_dir()`
has been set, otherwise we fallback to `fork(); chdir(); exec()`.
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.
projects / rust.git / log