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

This pulls in a commit which uses parallel xz encoding which should
hopefully help shave some time off the dist builders which spend an
inordinate amount of time compressing this data.

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,

…thewjasper

Adjust warning of -C extra-filename with -o.

If `--emit` includes multiple unnamed outputs, and `-o` was specified, and `-C extra-filename` was specified, the compiler would warn that `-C extra-filename` was ignored, but this is not true.  The "adapting" of the filenames includes the extra-filename info.

Since this is a little convoluted and hard to follow, here is a little chart to summarize when running with `rustc foo.rs -o xyz -C extra-filename=asdf`

`--emit` | Result
---------|--------
`link` | `xyz` (extra-filename ignored)
`link,dep-info` | `xyzasdf`, `xyzasdf.d` (this PR removes the incorrect warning)

As to whether or not this behavior is the best choice is another question.

…ark-Simulacrum

Update the `rust-installer` submodule

This pulls in a commit which uses parallel xz encoding which should
hopefully help shave some time off the dist builders which spend an
inordinate amount of time compressing this data.

…omez

rustdoc: remove unused derives and variants

Though many structs in rustdoc derive `RustcEncodable` and `RustcDecodable`, the impls do not appear to be used by the crate or its dependents. Removing them revealed some enum variants that are never constructed, too.

r? @GuillaumeGomez