Add Azure Pipelines configuration
Huge thanks to ＠johnterickson and ＠willsmythe for writing the initial config! ❤️
I applied some changes to the initial config and disabled most of the builders since we're not going to run all of them during the initial step for the evaluation.
[More details about our plans for the Azure Pipelines evaluation.](https://internals.rust-lang.org/t/update-on-the-ci-investigation/10056)
r? ＠alexcrichton ＠kennytm
cc ＠rust-lang/infra ＠ethomson ＠rylev
Solaris CI: Build with dilos2 stable
dilos2-testing has problems since the last repository update, so get the packages from dilos2 stable.
Fixes#61022.
This builder already is very close to the 2 hour mark and the debug
assertions aren't really buying us anything over what all the other
containers are enabling, so let's disable them for this slow builder.
* Clean up the `install-windows-build-deps.yml` file and add some more
comments where appropriate.
* Add some comments to `run.yml`
* Don't fast path the `rustfmt` submodule, but we'll take care of that
later if necessary.
Update books
## nomicon
1 commits in fb29b147be4d9a1f8e24aba753a7e1de537abf61..c656171b749b7307f21371dd0d3278efee5573b8
2019-04-22 19:10:29 -0400 to 2019-04-25 15:31:26 -0400
- Lifetimes: Updates to incorporate NLL (rust-lang-nursery/nomicon#101)
## reference
5 commits in 2a2de9ce095979978ad7b582daecf94e4070b916..862b669c395822bb0938781d74f860e5762ad4fb
2019-04-22 10:25:52 -0700 to 2019-05-04 23:41:35 -0700
- Typo (rust-lang-nursery/reference#606)
- Added missing ? to Generics from InherentImpl and TraitImpl (rust-lang-nursery/reference#604)
- Add missing ( to ExternalFunctionItem (rust-lang-nursery/reference#603)
- Remove unneeded | from AssignmentExpression (rust-lang-nursery/reference#601)
- Remove unneeded ( from TypePathSegment (rust-lang-nursery/reference#602)
## book
6 commits in db919bc6bb9071566e9c4f05053672133eaac33e..29fe982990e43b9367be0ff47abc82fb2123fd03
2019-04-15 20:11:03 -0400 to 2019-05-15 17:48:40 -0400
- Ignore a non-compiling test listing and add code to fix a test listing
- Remove nostarch snapshots I've checked in layout
- Reword error messages to maybe not need to wrap lines in print
- This example doesn't compile but wasn't marked as such
- Update install instructions for VS 2019 (rust-lang/book#1923)
- Switch IRC to Discord
## rust-by-example
9 commits in 1ff0f8e018838a710ebc0cc1a7bf74ebe73ad9f1..811c697b232c611ed754d279ed20643a0c4096f6
2019-04-15 08:15:32 -0300 to 2019-04-28 18:56:42 -0300
- Fix typo in dsl.md (rust-lang/rust-by-example#1187)
- File read lines (rust-lang/rust-by-example#1186)
- For https://github.com/rust-lang/rust-by-example/issues/1184closesrust-lang/rust-by-example#1184 (rust-lang/rust-by-example#1185)
- Link to Reference for macro_rules designators (rust-lang/rust-by-example#1182)
- Improve section Meta/Docs (rust-lang/rust-by-example#1183)
- Small improvements to various files (rust-lang/rust-by-example#1173)
- 19.2 Vectors Error in Code Example (rust-lang/rust-by-example#1178)
- For https://github.com/rust-lang/rust-by-example/issues/1175 (rust-lang/rust-by-example#1176)
- For https://github.com/rust-lang/rust-by-example/issues/1179 (rust-lang/rust-by-example#1180)
## rustc-guide
12 commits in 99e1b1d53656be08654df399fc200584aebb50e4..3cb727b62b953d59b4360d39aa68b6dc8f157655
2019-04-20 09:57:54 -0500 to 2019-05-07 09:53:32 -0500
- Fix typo, 'which' repeated twice
- [canonicalization] fix result canonicalization example (rust-lang/rustc-guide#304)
- Rename to RUSTC_LOG
- Added mention of universal ctags
- Fix link in walkthrough
- Remove IRC from discussion chats
- Bring the updating LLVM guide up to date
- use nightly rust for ci
- Fixed broken chalk links
- Add documentation for two-phase borrows
- Explain new powers of the `treat-err-as-bug` flag
- Update lowering-module test case
## edition-guide
3 commits in c413d42a207bd082f801ec0137c31b71e4bfed4c..581c6cccfaf995394ea9dcac362dc8e731c18558
2019-04-22 01:14:56 +0200 to 2019-05-06 12:47:44 -0700
- Fix typo in controlling-panics-with-std-panic.md (rust-lang-nursery/edition-guide#158)
- Fix links for book editions. (rust-lang-nursery/edition-guide#149)
- Update now that NLL is enabled in 2015. (rust-lang-nursery/edition-guide#157)
## embedded-book
3 commits in de3d55f521e657863df45260ebbca1b10527f662..9858872bd1b7dbba5ec27dc30d34eba00acd7ef9
2019-04-22 12:58:28 +0000 to 2019-05-02 18:56:54 +0000
- Update linux.md (rust-embedded/book#167)
- Clarify list of available targets for installation (rust-embedded/book#165)
- minor grammar fix (rust-embedded/book#188)
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.
r? @alexcrichton
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.
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.
ci: use a custom android sdk manager with pinning and mirroring
Google's own sdkmanager has two issues that make it unsuitable for us:
* Mirroring has to be done manually, which is annoying because we need to figure out on our own all the URLs to copy (I couldn't find any documentation when building this PR, had to use mitmproxy).
* There is no support for pinning, which means an update on Google's side can break our CI, as it happened multiple times.
This PR replaces all our usage of sdkmanager with a custom Python script which mimics its behavior, but with the two issues fixes.
sdkmanager's logic for installing packages is thankfully very simple: the package name (like `system-images;android-18;default;armeabi-v7a`) is the directory where the package should live (with `;` replaced with `/`), so to install a package we only need to extract its contents in the right directory.
r? @alexcrichton
cc @kennytm
fixes https://github.com/rust-lang/rust/issues/59778
musl: do not compress debug section
This should be beta nominated.
Fixes https://github.com/rust-lang/rust/issues/59411 (this time for real).
Test with `DEPLOY=1 ./src/ci/docker/run.sh dist-x86_64-musl`, without `DEPLOY=1` libs are built without debuginfo.
r? @alexcrichton
ci: pin android emulator to 28.0.23
Apparently Android Emulator 28.0.25 (the latest one) is broken for us, and `sdkmanager` doesn't have a way to pin a package to a specific version. This PR stops downloading the emulator from `sdkmanager`, downloading it manually instead.
Tested this locally and confirmed it works. I'll open an issue on Google's issue tracker later today.
Fixes https://github.com/rust-lang/rust/issues/59757
r? @kennytm
wasi: Use shared API for preopened fds
This commit updates the wasi target with supported added in
CraneStation/wasi-sysroot#10. That function allows both C and Rust to
cooperate in how preopened files are managed, enabling us to learn about
propened files through the same interface. The `open_parent` function in
the wasi `fs` module was updated to avoid its own initialization of a
global preopened map and instead delegate to libc to perform this
functionality.
This should both be more robust into the future in terms of handling
path logic as well as ensuring the propened map is correctly set up at
process boot time. This does currently require some unfortunate
allocations on our side, but if that becomes an issue we can always
paper over those in time!
This commit updates the wasi target with supported added in
CraneStation/wasi-sysroot#10. That function allows both C and Rust to
cooperate in how preopened files are managed, enabling us to learn about
propened files through the same interface. The `open_parent` function in
the wasi `fs` module was updated to avoid its own initialization of a
global preopened map and instead delegate to libc to perform this
functionality.
This should both be more robust into the future in terms of handling
path logic as well as ensuring the propened map is correctly set up at
process boot time. This does currently require some unfortunate
allocations on our side, but if that becomes an issue we can always
paper over those in time!
This commit adds the Armv8-M Baseline and Armv8-M Mainline with
FPU targets in the list of targets that
get their dist components built. It also update the build-manifest
so that this target gets also its dist components uploaded.
This commit adds a new wasm32-based target distributed through rustup,
supported in the standard library, and implemented in the compiler. The
`wasm32-unknown-wasi` target is intended to be a WebAssembly target
which matches the [WASI proposal recently announced.][LINK]. In summary
the WASI target is an effort to define a standard set of syscalls for
WebAssembly modules, allowing WebAssembly modules to not only be
portable across architectures but also be portable across environments
implementing this standard set of system calls.
The wasi target in libstd is still somewhat bare bones. This PR does not
fill out the filesystem, networking, threads, etc. Instead it only
provides the most basic of integration with the wasi syscalls, enabling
features like:
* `Instant::now` and `SystemTime::now` work
* `env::args` is hooked up
* `env::vars` will look up environment variables
* `println!` will print to standard out
* `process::{exit, abort}` should be hooked up appropriately
None of these APIs can work natively on the `wasm32-unknown-unknown`
target, but with the assumption of the WASI set of syscalls we're able
to provide implementations of these syscalls that engines can implement.
Currently the primary engine implementing wasi is [wasmtime], but more
will surely emerge!
In terms of future development of libstd, I think this is something
we'll probably want to discuss. The purpose of the WASI target is to
provide a standardized set of syscalls, but it's *also* to provide a
standard C sysroot for compiling C/C++ programs. This means it's
intended that functions like `read` and `write` are implemented for this
target with a relatively standard definition and implementation. It's
unclear, therefore, how we want to expose file descriptors and how we'll
want to implement system primitives. For example should `std::fs::File`
have a libc-based file descriptor underneath it? The raw wasi file
descriptor? We'll see! Currently these details are all intentionally
hidden and things we can change over time.
A `WasiFd` sample struct was added to the standard library as part of
this commit, but it's not currently used. It shows how all the wasi
syscalls could be ergonomically bound in Rust, and they offer a possible
implementation of primitives like `std::fs::File` if we bind wasi file
descriptors exactly.
Apart from the standard library, there's also the matter of how this
target is integrated with respect to its C standard library. The
reference sysroot, for example, provides managment of standard unix file
descriptors and also standard APIs like `open` (as opposed to the
relative `openat` inspiration for the wasi ssycalls). Currently the
standard library relies on the C sysroot symbols for operations such as
environment management, process exit, and `read`/`write` of stdio fds.
We want these operations in Rust to be interoperable with C if they're
used in the same process. Put another way, if Rust and C are linked into
the same WebAssembly binary they should work together, but that requires
that the same C standard library is used.
We also, however, want the `wasm32-unknown-wasi` target to be
usable-by-default with the Rust compiler without requiring a separate
toolchain to get downloaded and configured. With that in mind, there's
two modes of operation for the `wasm32-unknown-wasi` target:
1. By default the C standard library is statically provided inside of
`liblibc.rlib` distributed as part of the sysroot. This means that
you can `rustc foo.wasm --target wasm32-unknown-unknown` and you're
good to go, a fully workable wasi binary pops out. This is
incompatible with linking in C code, however, which may be compiled
against a different sysroot than the Rust code was previously
compiled against. In this mode the default of `rust-lld` is used to
link binaries.
2. For linking with C code, the `-C target-feature=-crt-static` flag
needs to be passed. This takes inspiration from the musl target for
this flag, but the idea is that you're no longer using the provided
static C runtime, but rather one will be provided externally. This
flag is intended to also get coupled with an external `clang`
compiler configured with its own sysroot. Therefore you'll typically
use this flag with `-C linker=/path/to/clang-script-wrapper`. Using
this mode the Rust code will continue to reference standard C
symbols, but the definition will be pulled in by the linker configured.
Alright so that's all the current state of this PR. I suspect we'll
definitely want to discuss this before landing of course! This PR is
coupled with libc changes as well which I'll be posting shortly.
[LINK]:
[wasmtime]:
