Bump to 1.25.0
* Bump the release version to 1.25
* Bump the bootstrap compiler to the recent beta
* Allow using unstable rustdoc features on beta - this fix has been applied to
the beta branch but needed to go to the master branch as well.
* Bump the release version to 1.25
* Bump the bootstrap compiler to the recent beta
* Allow using unstable rustdoc features on beta - this fix has been applied to
the beta branch but needed to go to the master branch as well.
rustdoc: add option to abort the process on markdown differences
In the efforts of keeping the std docs free of markdown warnings, this PR adds a stopgap measure to make sure the CI fails if it detects a markdown difference. It does this by adding a new unstable flag to rustdoc, `--deny-render-differences`, which bootstrap then passes to rustdoc when documenting std and friends.
The implementation is... probably not the cleanest option. It currently adds an extra branch after it prints the markdown warnings, which just prints a final line and calls `::std::process::abort(1)`. I did it like this because if it just panics regularly, it looks like an ICE, an even though `html::render::run` returns a Result, that Result is also just `expect`ed immediately, generating the same problem. This way bypasses the panic handler at the top of the thread and looks like a proper failure. Since i don't have a real error Handler there, this is the best i can do without pulling in a real error system for rustdoc.
This PR is blocked on https://github.com/rust-lang/rust/pull/46853, which will fix the rendering differences that were present on master when i started this branch.
[auto-toolstate] Upload the toolstate result to an external git repository, and removes BuildExpectation
This PR consists of 3 commits.
1. (Steps 4–6) The `toolstate.json` output previously collected is now pushed to the https://github.com/rust-lang-nursery/rust-toolstate repository.
2. (Step 7) Revert commit ab018c7, thus removing all traces of `BuildExpectation` and `toolstate.toml`.
3. (Step 8) Adjust CONTRIBUTION.md for the new procedure.
These are the last steps of #45861. After this PR, the toolstate will be automatically computed and published to https://rust-lang-nursery.github.io/rust-toolstate/. There is no need to manage toolstate.toml again.
Closes#45861.
This reverts commit ab018c76e1.
This also adds the `ToolBuild::is_ext_tool` field to replace the previous
`ToolBuild::expectation` field, to indicate whether a build-failure of
certain tool is essential.
Re-do the FreeBSD cross-builds to use Clang and libc++. Fixes#44433
Reviving #45077, from @jld:
> The main goal here is to use FreeBSD's normal libc++, instead of
> statically linking the libstdc++ packaged with GCC, because that
> libstdc++ has bugs that cause rustc to deadlock inside LLVM.
>
> But the easiest way to use libc++ is to switch the build from GCC to
> Clang, and the Clang package in the Ubuntu image already knows how to
> cross-compile (given a sysroot and preferably cross-binutils), so the
> toolchain script now uses that instead of building a custom compiler.
>
> This also de-duplicates the build-toolchain.sh script.
#45077 was close but didn't quite make it. I rebased @jld's work off the current `master` and started with that.
I was able to determine that this Travis error (https://github.com/rust-lang/rust/pull/45077#issuecomment-336029862) was ultimately caused by `src/librustc_llvm/build.rs` attempting to follow a wrong value in `LLVM_STATIC_STDCPP` (https://github.com/rust-lang/rust/pull/45077#issuecomment-352639456).
I looked at the downstream port for FreeBSD (https://svnweb.freebsd.org/ports/head/lang/rust/) and it seems like they do not use `--enable-llvm-static-stdcpp`.
Since `libc++` is included in the FreeBSD 10+ base system, we don't need to statically link it either?
So in b989428f7d I have set the FreeBSD build to not actually use `LLVM_STATIC_STDCPP`.
I was able to run `./src/ci/docker/run.sh` with both `dist-i686-freebsd` and `dist-x86_64-freebsd` successfully and in about 1 minute of testing it seemed like the dist-x86_64-freebsd results worked on a FreeBSD 11 system.
It should fix#44433, which seems to be affecting many potential users. Also FreeBSD users should be able to `./x.py build` which should help anyone who wants to upstream fixes for FreeBSD.
Questions:
Does this approach seem to be the right way to go? Do we actually really want to statically link `libc++`? (I tried that here, but it ultimately ran into a roadblock on x86_64: https://github.com/rust-lang/rust/pull/45077#issuecomment-353293414)
Can we rewrite the comment here to be more clear about why some systems aren't going to actually use this option:
b989428f7d/src/bootstrap/compile.rs (L550-L553)
How does this affect users of older FreeBSD systems? It seemed like no one was complaining about using a 10.3 base version in the thread for #45077. FreeBSD seems to only officially support 10.3, 10.4, and 11.x right now, do we have to consider older users? The `libc++` stuff came in for FreeBSD 10, older FreeBSD used `libstdc++`.
Looks like @alexcrichton was leading the discussion on the previous issue:
r? @alexcrichton
Let me know what I can do to help get this through.
The code inside this conditional will not work on FreeBSD 10+ because
those versions use clang and libc++ rather than libstdc++.
Since FreeBSD comes with libc++ in the base, presumably all 10+ systems
will have it present.
Searching for libstdc++.a will not work if it is not present. As a
result, this would previously have set `LLVM_STATIC_STDCPP=libstdc++.a`,
which isn't a valid path and caused problems later on when building
`librustc_llvm`.
This could possibly be updated in the future to look for `libc++.a` on
FreeBSD, by expanding the code inside the conditional. In one attempt
to run this on x86_64-freebsd, I found that libc++ was not compiled with
PIC, so it failed anyway.
rustbuild: Fix a typo with the Cargo book
The usage of `Path::new` prevented out-of-tree builds (like the bots do) from
working by accident!
Closes#46195
This commit allocates a builder to running wasm32 tests on Travis. Not all test
suites pass right now so this is starting out with just the run-pass and the
libcore test suites. This'll hopefully give us a pretty broad set of coverage
for integration in rustc itself as well as a somewhat broad coverage of the llvm
backend itself through integration/unit tests.
[auto-toolstate][1/8] Always ignore build failure of failable tools (rls, rustfmt, clippy)
If build failed for these tools, they will be automatically skipped from distribution, and will not fail the whole build.
Test failures are *not* ignored, nor build failure of other tools (e.g. cargo). Therefore it should have no observable effect to the current CI system.
This is step 1/8 of automatic management of broken tools #45861. The purpose is concentrate all failure detection about tools into a single CI job for easy management, while keeping the ability to distribute these tools in the nightlies.
r? @Mark-Simulacrum
This commit alters how we compile LLVM by default enabling the WebAssembly
backend. This then also adds the wasm32-unknown-unknown target to get compiled
on the `cross` builder and distributed through rustup. Tests are not yet enabled
for this target but that should hopefully be coming soon!
This commit updates LLVM to fix#45511 (https://reviews.llvm.org/D39981) and
also reenables ThinLTO for libtest now that we shouldn't hit #45768. This also
opportunistically enables ThinLTO for libstd which was previously blocked
(#45661) on test failures related to debuginfo with a presumed cause of #45511.
Closes#45511
Allow filtering analysis by reachability
Fixes#43521.
Fixes https://github.com/nrc/rls-analysis/issues/79.
This PR allows a user to filter items present in the save-analysis data by setting the `reachable_only` config option. This option is intended for use by the new rustdoc. The PR isn't quite finished, because it's dependent on a new release of rls-data, but I want to make sure that the approach is valid.
https://github.com/nrc/rls-analysis/issues/79 mentions that `pub use` might need to be handled, but my thinking is that the consumer of the analysis data would be able to infer which imports are `pub use`, and which items are only reachable through `pub use`, so that doesn't need to be handled here.
r? @nrc
If build failed for these tools, they will be automatically skipped from
distribution, and will not fail the whole build.
Test failures are *not* ignored, nor build failure of other tools (e.g.
cargo). Therefore it should have no observable effect to the current CI
system.
This is step 1/8 of automatic management of broken tools #45861.
rustbuild: distribute cargo-fmt alongside rustfmt
Not sure whether we want that nor if it's the right way to do so, but it feels quite weird to have rustfmt without cargo-fmt. Or are there other plans wrt that?
What do you think @nrc ?
Fix broken CSS for book redirect pages
rust.css has to be next to the font files so we shouldn't copy it for
only the book redirect pages, instead just use the version that is
already there.
This also removes the duplicate code creating version_info.html.
Fixes: #45974
std: Add a new wasm32-unknown-unknown target
This commit adds a new target to the compiler: wasm32-unknown-unknown. This target is a reimagining of what it looks like to generate WebAssembly code from Rust. Instead of using Emscripten which can bring with it a weighty runtime this instead is a target which uses only the LLVM backend for WebAssembly and a "custom linker" for now which will hopefully one day be direct calls to lld.
Notable features of this target include:
* There is zero runtime footprint. The target assumes nothing exists other than the wasm32 instruction set.
* There is zero toolchain footprint beyond adding the target. No custom linker is needed, rustc contains everything.
* Very small wasm modules can be generated directly from Rust code using this target.
* Most of the standard library is stubbed out to return an error, but anything related to allocation works (aka `HashMap`, `Vec`, etc).
* Naturally, any `#[no_std]` crate should be 100% compatible with this new target.
This target is currently somewhat janky due to how linking works. The "linking" is currently unconditional whole program LTO (aka LLVM is being used as a linker). Naturally that means compiling programs is pretty slow! Eventually though this target should have a linker.
This target is also intended to be quite experimental. I'm hoping that this can act as a catalyst for further experimentation in Rust with WebAssembly. Breaking changes are very likely to land to this target, so it's not recommended to rely on it in any critical capacity yet. We'll let you know when it's "production ready".
### Building yourself
First you'll need to configure the build of LLVM and enable this target
```
$ ./configure --target=wasm32-unknown-unknown --set llvm.experimental-targets=WebAssembly
```
Next you'll want to remove any previously compiled LLVM as it needs to be rebuilt with WebAssembly support. You can do that with:
```
$ rm -rf build
```
And then you're good to go! A `./x.py build` should give you a rustc with the appropriate libstd target.
### Test support
Currently testing-wise this target is looking pretty good but isn't complete. I've got almost the entire `run-pass` test suite working with this target (lots of tests ignored, but many passing as well). The `core` test suite is [still getting LLVM bugs fixed](https://reviews.llvm.org/D39866) to get that working and will take some time. Relatively simple programs all seem to work though!
In general I've only tested this with a local fork that makes use of LLVM 5 rather than our current LLVM 4 on master. The LLVM 4 WebAssembly backend AFAIK isn't broken per se but is likely missing bug fixes available on LLVM 5. I'm hoping though that we can decouple the LLVM 5 upgrade and adding this wasm target!
### But the modules generated are huge!
It's worth nothing that you may not immediately see the "smallest possible wasm module" for the input you feed to rustc. For various reasons it's very difficult to get rid of the final "bloat" in vanilla rustc (again, a real linker should fix all this). For now what you'll have to do is:
cargo install --git https://github.com/alexcrichton/wasm-gc
wasm-gc foo.wasm bar.wasm
And then `bar.wasm` should be the smallest we can get it!
---
In any case for now I'd love feedback on this, particularly on the various integration points if you've got better ideas of how to approach them!
This commit adds a new target to the compiler: wasm32-unknown-unknown. This
target is a reimagining of what it looks like to generate WebAssembly code from
Rust. Instead of using Emscripten which can bring with it a weighty runtime this
instead is a target which uses only the LLVM backend for WebAssembly and a
"custom linker" for now which will hopefully one day be direct calls to lld.
Notable features of this target include:
* There is zero runtime footprint. The target assumes nothing exists other than
the wasm32 instruction set.
* There is zero toolchain footprint beyond adding the target. No custom linker
is needed, rustc contains everything.
* Very small wasm modules can be generated directly from Rust code using this
target.
* Most of the standard library is stubbed out to return an error, but anything
related to allocation works (aka `HashMap`, `Vec`, etc).
* Naturally, any `#[no_std]` crate should be 100% compatible with this new
target.
This target is currently somewhat janky due to how linking works. The "linking"
is currently unconditional whole program LTO (aka LLVM is being used as a
linker). Naturally that means compiling programs is pretty slow! Eventually
though this target should have a linker.
This target is also intended to be quite experimental. I'm hoping that this can
act as a catalyst for further experimentation in Rust with WebAssembly. Breaking
changes are very likely to land to this target, so it's not recommended to rely
on it in any critical capacity yet. We'll let you know when it's "production
ready".
---
Currently testing-wise this target is looking pretty good but isn't complete.
I've got almost the entire `run-pass` test suite working with this target (lots
of tests ignored, but many passing as well). The `core` test suite is still
getting LLVM bugs fixed to get that working and will take some time. Relatively
simple programs all seem to work though!
---
It's worth nothing that you may not immediately see the "smallest possible wasm
module" for the input you feed to rustc. For various reasons it's very difficult
to get rid of the final "bloat" in vanilla rustc (again, a real linker should
fix all this). For now what you'll have to do is:
cargo install --git https://github.com/alexcrichton/wasm-gc
wasm-gc foo.wasm bar.wasm
And then `bar.wasm` should be the smallest we can get it!
---
In any case for now I'd love feedback on this, particularly on the various
integration points if you've got better ideas of how to approach them!
Fix a bug where the rustfmt tarball was not being produced
r? @alexcrichton
This makes rustfmt a dep of 'extended', which seems to be necessary for the rustfmt dist step to actually get run.
