bors [Fri, 10 May 2019 07:02:38 +0000 (07:02 +0000)]
Auto merge of #60585 - sunfishcode:wasm32-wasi, r=alexcrichton
Omit the vendor component in the WASI triple
This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor
component. This follows aarch64-linux-android, x86_64-fuchsia, and others in
omitting the vendor field, which has the advantage of aligning with the
[multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being
less noisy.
bors [Fri, 10 May 2019 00:51:14 +0000 (00:51 +0000)]
Auto merge of #60683 - Centril:rollup-p05qh5d, r=Centril
Rollup of 8 pull requests
Successful merges:
- #59348 (Clean up and add tests for slice drop shims)
- #60188 (Identify when a stmt could have been parsed as an expr)
- #60234 (std: Derive `Default` for `io::Cursor`)
- #60618 (Comment ext::tt::transcribe)
- #60648 (Skip codegen for one UI test with long file path)
- #60671 (remove unneeded `extern crate`s from build tools)
- #60675 (Remove the old await! macro)
- #60676 (Fix async desugaring providing wrong input to procedural macros.)
Rollup merge of #60676 - davidtwco:issue-60674, r=cramertj
Fix async desugaring providing wrong input to procedural macros.
Fixes #60674.
This PR fixes a minor oversight introduced by #60535 where unused `mut` binding modes were removed from the arguments to an `async fn` (as they were added to the statement that we insert into the closure body). However, this meant that the input to procedural macros was incorrect. This removes that and instead fixes the `unused_mut` error that it avoided.
Rollup merge of #60648 - petrochenkov:shorten2, r=Dylan-DPC
Skip codegen for one UI test with long file path
The path to this test is so long that object files produced by it hit some path length limit on Windows and linker cannot find them.
The workaround here is to skip codegen and avoid producing object files, this test doesn't need them anyway.
Rollup merge of #60188 - estebank:recover-block, r=varkor
Identify when a stmt could have been parsed as an expr
There are some expressions that can be parsed as a statement without
a trailing semicolon depending on the context, which can lead to
confusing errors due to the same looking code being accepted in some
places and not others. Identify these cases and suggest enclosing in
parenthesis making the parse non-ambiguous without changing the
accepted grammar.
bors [Thu, 9 May 2019 21:50:46 +0000 (21:50 +0000)]
Auto merge of #60665 - pietroalbini:upgrade-ci-images, r=alexcrichton
Upgrade non-LTS Ubuntu images in CI
This PR bumps `dist-various-2` to 18.04 LTS and both `x86_64-gnu` and `x86_64-gnu-debug` to 19.04.
Another change is the switch to [rust-lang/mirror-google-fuchsia-zircon](https://github.com/rust-lang/mirror-google-fuchsia-zircon) as the Zircon repository, used during Fuchsia tests: the original repository ([fuchsia.googlesource.com/zircon](https://fuchsia.googlesource.com/zircon)) is now behind a login wall and it doesn't contain anything at all.
r? @alexcrichton
cc @cramertj -- what's happening on the Fuchsia side?
bors [Thu, 9 May 2019 18:43:00 +0000 (18:43 +0000)]
Auto merge of #60672 - Centril:rollup-fhcx463, r=Centril
Rollup of 5 pull requests
Successful merges:
- #60601 (Add a `cast` method to raw pointers.)
- #60638 (pin: make the to-module link more visible)
- #60647 (cleanup: Remove `DefIndexAddressSpace`)
- #60656 (Inline some Cursor calls for slices)
- #60657 (Stabilize and re-export core::array in std)
Dan Gohman [Wed, 1 May 2019 02:37:25 +0000 (19:37 -0700)]
Omit the vendor component in the WASI triple
This renames wasm32-unknown-wasi to wasm32-wasi, omitting the vendor
component. This follows aarch64-linux-android, x86_64-fuchsia, and others in
omitting the vendor field, which has the advantage of aligning with the
[multiarch tuple](https://wiki.debian.org/Multiarch/Tuples), and of being
less noisy.
David Wood [Thu, 9 May 2019 18:10:27 +0000 (19:10 +0100)]
Do not modify mutability of simple bindings.
This commit removes the modification of the mutability of simple
bindings. While the mutability isn't used, it is important that it is
kept so that the input to procedural macros matches what the user wrote.
This commit also modifies the span of the binding mode so that it is
considered a compiler desugaring and won't be linted against for being
unused..
Rollup merge of #60656 - petertodd:2019-inline-cursor-over-slice, r=sfackler
Inline some Cursor calls for slices
(Partially) brings back https://github.com/rust-lang/rust/pull/33921
I've noticed in some serialization code I was writing that writes to slices produce much, much, worse code than you'd expect even with optimizations turned on. For example, you'd expect something like this to be zero cost:
```
use std::io::{self, Cursor, Write};
pub fn serialize((a, b): (u64, u64)) -> [u8;8+8] {
let mut r = [0u8;16];
{
let mut w = Cursor::new(&mut r[..]);
w.write(&a.to_le_bytes()).unwrap();
w.write(&b.to_le_bytes()).unwrap();
}
r
}
```
...but it compiles down to [dozens of instructions](https://rust.godbolt.org/z/bdwDzb) because the `slice_write()` calls aren't inlined, which in turn means `unwrap()` can't be optimized away, and so on.
To be clear, this pull-req isn't sufficient by itself: if we want to go down that path we also need to add `#[inline]`'s to the default implementations for functions like `write_all()` in the `Write` trait and so on, or implement them separately in the `Cursor` impls. But I figured I'd start a conversation about what tradeoffs we're expecting here.
Rollup merge of #60647 - petrochenkov:nospace, r=michaelwoerister
cleanup: Remove `DefIndexAddressSpace`
The scheme with two address spaces for `DefIndex` was needed in the past, but apparently not needed anymore (after removing `DefId`s from locals and `HirId`-ification).
Pietro Albini [Thu, 9 May 2019 09:32:41 +0000 (11:32 +0200)]
ci: use our own mirror for fuchsia's zircon repository
The canonical repository on fuchsia.googlesource.com is not accessible
anymore, neither for anonymous access nor logged in access. This commit
switches our CI to fetch the repository from our own mirror.
bors [Wed, 8 May 2019 22:59:23 +0000 (22:59 +0000)]
Auto merge of #60651 - Centril:rollup-zoamjfk, r=Centril
Rollup of 8 pull requests
Successful merges:
- #59979 (to_xe_bytes for isize and usize returns an array of different size)
- #60491 (std: Update compiler-builtins crate)
- #60550 (Add tests for concrete const types)
- #60572 (Add test for #59972)
- #60627 (test for #50518)
- #60634 (Document + Cleanup lang_items.rs)
- #60641 (Instead of ICEing on incorrect pattern, use delay_span_bug)
- #60644 (Use `delay_span_bug` for "Failed to unify obligation")
Where's the best place to add this test? I *think* we want "compile-pass" for this test (no need to run a binary, and not running saves us a millisecond of process creation) , but there's no compile-pass anymore.
Should this be UI test with empty stdout, stderr and zero return code?
Rollup merge of #60550 - skinny121:concrete_const_tests, r=varkor
Add tests for concrete const types
In response to the request for help in https://github.com/rust-lang/rust/issues/44580#issuecomment-488819344, I have added several ui tests around the use of concrete const types, i.e. A<2>.
Rollup merge of #59979 - stepancheg:num-size, r=ehuss
to_xe_bytes for isize and usize returns an array of different size
... on different platforms.
Official rustdoc of
[`usize::to_le_bytes`](https://doc.rust-lang.org/std/primitive.usize.html#method.to_le_bytes)
displays signature
```
pub fn to_ne_bytes(self) -> [u8; 8]
```
which might be misleading: this function returns 4 bytes on 32-bit
systems.
With this commit applied rustdoc for `isize` and `usize` is this:
<img width="740" alt="2019-04-15_0020" src="https://user-images.githubusercontent.com/28969/56100765-9f69b380-5f14-11e9-974c-daa25edaa881.png">
bors [Wed, 8 May 2019 18:38:14 +0000 (18:38 +0000)]
Auto merge of #60402 - michaelwoerister:update-profiler-rt-build, r=alexcrichton
libprofiler_builtins: Set compilation flags more correctly for C code.
In particular, set `COMPILER_RT_HAS_FCNTL_LCK` and `COMPILER_RT_HAS_ATOMICS` as appropriate. This should get rid of the various runtime warnings when executing instrumented binaries.
The build script is using a heuristic here that hopefully is sufficient for the time being.
bors [Wed, 8 May 2019 08:26:48 +0000 (08:26 +0000)]
Auto merge of #60378 - froydnj:apple-target-modifications, r=michaelwoerister
conditionally modify darwin targets to macosx targets with versions
We need this behavior so that Rust LLVM IR objects match the target triple for Clang LLVM IR objects. This matching then convinces the linker that yes, you really can do cross-language LTO with objects from different compilers.
The newly-added tests seem to pass locally on x86_64-unknown-linux-gnu. I haven't done a full test run or tried the new compiler in an cross-language LTO setup yet.
bors [Tue, 7 May 2019 22:33:12 +0000 (22:33 +0000)]
Auto merge of #60586 - cramertj:await, r=oli-obk
Implement built-in await syntax
Adds support for .await under the existing async_await feature gate.
Moves macro-like await! syntax to the await_macro feature gate.
Removes support for `await` as a non-keyword under the `async_await`
feature.
This new syntax is not final, but is the consensus solution proposed by the lang team, as explained in https://boats.gitlab.io/blog/post/await-decision/
Taylor Cramer [Thu, 18 Apr 2019 19:55:23 +0000 (12:55 -0700)]
Implement built-in await syntax
Adds support for .await under the existing async_await feature gate.
Moves macro-like await! syntax to the await_macro feature gate.
Removes support for `await` as a non-keyword under the `async_await`
feature.
bors [Tue, 7 May 2019 19:39:52 +0000 (19:39 +0000)]
Auto merge of #60612 - Centril:rollup-61drhqt, r=Centril
Rollup of 5 pull requests
Successful merges:
- #60489 (Remove hamburger button from source code page)
- #60535 (Correct handling of arguments in async fn)
- #60579 (Rename `ParamTy::idx` to `ParamTy::index`)
- #60583 (Fix parsing issue with negative literals as const generic arguments)
- #60609 (Be a bit more explicit asserting over the vec rather than the len)
David Wood [Mon, 6 May 2019 21:56:47 +0000 (22:56 +0100)]
Trust signature over return expr for generators.
This commit extends the logic used to determine what the expected
signature of a closure is so that it can also determine the expected
signature of a generator. This improves a diagnostic where the fn
signature was blamed instead of the generator body. It doesn't fix
fix the diagnostic for `async fn`.
bors [Tue, 7 May 2019 05:53:18 +0000 (05:53 +0000)]
Auto merge of #60596 - ehuss:update-cargo, r=alexcrichton
Update cargo
12 commits in beb8fcb5248dc2e6aa488af9613216d5ccb31c6a..759b6161a328db1d4863139e90875308ecd25a75
2019-04-30 23:58:00 +0000 to 2019-05-06 20:47:49 +0000
- Small things (rust-lang/cargo#6910)
- Fix skipping over invalid registry packages (rust-lang/cargo#6912)
- Fixes rust-lang/cargo#6874 (rust-lang/cargo#6905)
- doc: Format examples of version to ease reading (rust-lang/cargo#6907)
- fix more typos (codespell) (rust-lang/cargo#6903)
- Parse less JSON on null builds (rust-lang/cargo#6880)
- chore: Update opener to 0.4 (rust-lang/cargo#6902)
- Update documentation for auto-discovery. (rust-lang/cargo#6898)
- Update some doc links. (rust-lang/cargo#6897)
- Default Cargo.toml template provide help for completing the metadata (rust-lang/cargo#6881)
- Run 'cargo fmt --all' (rust-lang/cargo#6896)
- Refactor command definition (rust-lang/cargo#6894)
bors [Tue, 7 May 2019 02:58:40 +0000 (02:58 +0000)]
Auto merge of #60464 - eddyb:not-overly-specific-pipelining, r=alexcrichton
rustc: rename -Z emit-directives to -Z emit-artifact-notifications and simplify the output.
This is my take on #60006 / #60419 (see https://github.com/rust-lang/rust/pull/60006#discussion_r275983732).
I'm not too attached the "notifications" part, it's pretty much bikeshed material.
**EDIT**: for "artifact", @matklad pointed out Cargo already uses it (in https://github.com/rust-lang/rust/pull/60464#issuecomment-488576998)
The first two commits are fixes that could be landed independently, especially the `compiletest` one, which removes the need for any of the normalization added in #60006 to land the test.
The last commit enables the emission for all outputs, which was my main suggestion for #60006, mostly to show that it's minimal and not really a "scope creep" (as suggested in https://github.com/rust-lang/rust/pull/60006#discussion_r279964081).
David Wood [Mon, 6 May 2019 19:45:47 +0000 (20:45 +0100)]
Add test for current behaviour.
This commit adds a test for the current behaviour of signature deduction
of generators when there is a type mismatch between the return type of
the function body and the signature.
bors [Mon, 6 May 2019 20:54:30 +0000 (20:54 +0000)]
Auto merge of #60526 - alexcrichton:wasm-main-symbols, r=oli-obk
rustc: Always handle exported symbols on the wasm target
Currently when linking an artifact rustc will only conditionally call
the `Linker::export_symbols` function, but this causes issues on some
targets, like WebAssembly, where it means that executable outputs will
not have the same symbols exported that cdylib outputs have. This commit
sinks the conditional call to `export_symbols` inside the various
implementations of the function that still need it, and otherwise the
wasm linker is configured to always pass through symbol visibility
lists.
bors [Mon, 6 May 2019 16:43:25 +0000 (16:43 +0000)]
Auto merge of #53645 - varkor:const-generics-redux, r=eddyb
The Genesis of Generic Germination
*Long had its coming been foretold: a collaborative effort with @yodaldevoid, set in motion by @jplatte, to beget a new Kind: one of a very different Sort to those that come before it. Amidst promises of ineffable powers previously thought unobtainable, few dared believe that the prophecies were true. But as they gazed upon that which claimed to be the Beginning, a few gentle sparks of hope fluttered deep within. It was not Time yet. But it was a Sign. And maybe, for some, that was enough.*
There's a long way to go, but we're at the point where we would benefit from GitHub's reviewing capabilities.