So far it is assumed that using a DLL as a -l parameter argument is ok,
but the assumption doesn't hold when compiling the native code with
llvm.
In which case, an import library is required, so let's build one
This also requires the cargo counterpart to add the import library in
the stamp files, at least when compiling libstd. Otherwise, the files
don't get uplifted

So that uwp-windows-gnu also gets its startup objects built

libgcc's support is using forbidden functions

As Rtl* functions are not allowed there

Attempt to create sockets with the WSA_FLAG_NO_HANDLE_INHERIT flag, and
handle the potential error gracefully (as the flag isn't support on
Windows 7 before SP1)

Or rather expose it, but always return an error

The required functions are not available, so hope for the best

…gistered

This avoids adding archives multiple times, which results in duplicate
objects in the resulting rlib, leading to symbol collision and link
failures. This could happen when crate contains multiple link attributes
that all reference the same archive.

Add support for UWP targets

Hi,

This pull request aims at adding support for UWP (Universal Windows Apps) platform.
A few notes:
- This requires a very recent mingw-w64 version (containing this commit and the previous related ones: mirror/mingw-w64@e8c433c#diff-eefdfbfe9cec5f4ebab88c9a64d423a9)
- This was tested using LLVM/clang rather than gcc, and so far it assumes that LLVM/clang will be the native compiler. This is mostly due to the fact that the support for exceptions/stack unwinding for UWP got much more attention in libunwind
- The "uwp" part of the target needs support for it in the `cc-rs` & `backtrace-rs` crates. I'll create the MR there right after I submit this one and will link everything together, but I'm not sure what's the correct way of dealing with external dependencies in the context of rust
- Enabling import libraries and copying them across stages requires a change in cargo, for which I'll open a MR right after I submit this one as well
- The i686 stack unwinding is unsupported for now, because LLVM assumes SjLj, while rust seems to assume SEH will be used. I'm unsure how to fix this

Also, this is my first encounter with rust, so please bear with my code, it might not feel so idiomatic or even correct :)

I'm pretty sure there's a way of doing things in a cleaner way when it comes to win/c.rs, maybe having a UWP & desktop specific modules, and import those conditionally? It doesn't feel right to sprinkle `#[cfg(...)]` all over the place

Off course, I'll gladly update anything you see fit (to the extent of my abilities/knowledge :) )!

Thanks,

Feature gate `rustc` attributes harder

Fixes rust-lang#62116

Derive which queries to save using the proc macro

Based on rust-lang#62166.

r? @eddyb

…ichton

Update rustfmt to 1.3.1

[Changelog](https://github.com/rust-lang/rustfmt/blob/master/CHANGELOG.md#131-2019-06-30).

…es, r=cramertj

Check if the archive has already been added to avoid duplicates

This avoids adding archives multiple times, which results in duplicate
objects in the resulting rlib, leading to symbol collision and link
failures. This could happen when crate contains multiple link attributes
that all reference the same archive.

…mertj

Move `async || ...` closures into `#![feature(async_closure)]`

The `async || expr` syntax is moved out from `#![feature(async_await)]` into its own gate `#![feature(async_closure)]`.

New tracking issue: rust-lang#62290

Closes rust-lang#62214.

cc rust-lang#62149

r? @varkor

…, r=cramertj

Reduce reliance on `await!(...)` macro

Only the last commit is new.

r? @cramertj