This commit adds support for sccache, a ccache-like compiler which works on MSVC
and stores results into an S3 bucket. This also switches over all Travis and
AppVeyor automation to using sccache to ensure a shared and unified cache over
time which can be shared across builders.
The support for sccache manifests as a new `--enable-sccache` option which
instructs us to configure LLVM differently to use a 'sccache' binary instead of
a 'ccache' binary. All docker images for Travis builds are updated to download
Mozilla's tooltool builds of sccache onto various containers and systems.
Additionally a new `rust-lang-ci-sccache` bucket is configured to hold all of
our ccache goodies.
[LLVM 4.0] Update LLVM global variable debug info API for 4.0
This teaches Rust about an LLVM 4.0 API change for creating debug info
for global variables.
This change was made in upstream LLVM patch https://reviews.llvm.org/D20147
This is almost a 1:1 copy of how clang did it in http://reviews.llvm.org/D20415
Document --test-args for rustbuild
There are three changes:
* Replace --filter with --test-args
* Delete `./x.py test src/test/run-pass/assert-*` example, which doesn't work
* As driveby, update Buildbot URLs to https
Fix#38275.
r? @alexcrichton
Fix travis builds
After reading some articles [1] [2] yesterday about Docker and the "init"
process I got to thinking about the problems that we've been seeing on Travis.
The basic problem is that a Linux system may need an "init" process to work
properly when processes become zombies. Docker by default doesn't handle this
and the root process typically isn't an init process, so this can occasionally
cause quite a few problems.
We've been seeing spurious errors on Travis inside containers which look like
OOM and such, but my guess is that zombie processes were being reparented to the
top-level shell. The shell didn't expect the zombies and then behaved very
strangely.
This commit fixes these problems by using Yelp's "dumb-init" program [2] as the
init process in all of our containers. This ensures that there's a valid init
ready to reap children when they're reparented, which our test suite apparently
generates a bunch of throughout the tests and such.
[1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/
[2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
This teaches Rust about an LLVM 4.0 API change for creating debug info
for global variables.
This change was made in upstream LLVM patch https://reviews.llvm.org/D20147
This is almost 1:1 copy of how clang did it in http://reviews.llvm.org/D20415
libtest: add --exact to make filter matching exact
Filter matching is by substring by default. This makes it impossible
to run a single test if its name is a substring of some other test.
For example, its not possible to run just `mymod::test` with these
tests:
```
mymod::test
mymod::test1
mymod::test_module::moretests
```
You could declare by convention that no test has a name that's a
substring of another test, but that's not really practical.
This PR adds the `--exact` flag, to make filter matching exactly
match the complete name.
Another round of nightly fixes
Another three separate errors happened last night:
* Race condition in save analysis failed the OX build
* Packaging docs that don't exist failed the Android build
* Packaging save-analysis that doesn't exist failed the cross host builds
It just never ends...
This commit skips a few more dist tragets during compilation which shouldn't be
necessary.
* First, when packaging std we only take action when the host target is the
build target. Otherwise we package the same artifacts a number of times, which
shouldn't be necessary.
* Next, we apply the same logic to the save-analysis build. This is actually
required for correctness as the build compiler is the only one which actually
has save analysis information. This should fix an error seen on nightlies.
The OSX bots failed last night due a race condition in save analysis where
concurrent calls to `fs::create_dir_all` conflicted with one another. This
replaces the relevant function call with `fs::create_dir_racy` which is defined
internally to the compiler.
[LLVM 4.0] Move debuginfo alignment argument
Alignment was removed from createBasicType and moved to
- createGlobalVariable
- createAutoVariable
- createStaticMemberType (unused in Rust)
- createTempGlobalVariableFwdDecl (unused in Rust)
e69c459a6e
[MSP430] Do not generate '@' character in symbol names.
MSP430 assembler does not like '@' character in symbol names, so we need
to replace it with some other character.
Fixes#38116
After reading some articles [1] [2] yesterday about Docker and the "init"
process I got to thinking about the problems that we've been seeing on Travis.
The basic problem is that a Linux system may need an "init" process to work
properly when processes become zombies. Docker by default doesn't handle this
and the root process typically isn't an init process, so this can occasionally
cause quite a few problems.
We've been seeing spurious errors on Travis inside containers which look like
OOM and such, but my guess is that zombie processes were being reparented to the
top-level shell. The shell didn't expect the zombies and then behaved very
strangely.
This commit fixes these problems by using Yelp's "dumb-init" program [2] as the
init process in all of our containers. This ensures that there's a valid init
ready to reap children when they're reparented, which our test suite apparently
generates a bunch of throughout the tests and such.
[1]: https://blog.phusion.nl/2015/01/20/docker-and-the-pid-1-zombie-reaping-problem/
[2]: https://engineeringblog.yelp.com/2016/01/dumb-init-an-init-for-docker.html
feat(rustdoc): harmonise error messages
Based on unix tools wording, it follows a standard format: `program_name: context: error message`, potentially prompting the user to use the `--help` option.
This is clearly meant to trigger some discussion on #38084, as messages still use `stdout` and `stderr` somewhat arbitrarily, and there are a few `error!()` calls as well.
rustdoc: Remove broken src links from reexported items from macros
When an item is defined in an external macro it doesn't get a real
filename so we need to filter out these when generating src links for
reexported items.
Avoid using locally installed Source Code Pro font (fixes#24355).
In some versions of this font the ampersands are drawn badly.
A doc tree built with this change is at https://storage.googleapis.com/mbp-rust-builds/fonts/doc/std/index.html
I'm not seeing this problem locally so I'm not sure this fixes it, but based on the diagnosis in the bug it should.
I've made this a minimal change by only removing the one problematic font but maybe for consistency every font should be read from the Rust docs tree?
Improve and fix mpsc documentation
Closes#37915
This commit enhances documentation with several links and
fixes an error in the `sync_channel` documentation as well:
`send` doesn't panic when the senders are all disconnected
r? @steveklabnik
Git worktrees have this as a file and typically won't work inside docker
containers, but that's ok, so instead of just checking for existence check for a
directory to see if the git commands will succeed.
This commit updates the gcc-rs dependency to 0.3.40 to pick up a fix for i686
musl where we needed to pass an extra linker flag to get autoconf's detection of
executables working correctly.
Based on unix tools wording, it follows a standard format:
`program_name: context: error message` on stderr, prompting the user
to use the `--help` option in case of misuse.
Alignment was removed from createBasicType and moved to
- createGlobalVariable
- createAutoVariable
- createStaticMemberType (unused in Rust)
- createTempGlobalVariableFwdDecl (unused in Rust)
e69c459a6e
Simplify use of mir_opt_level
Remove the unused top level option by the same name, and retain the
debug option.
Use -Zmir-opt-level=1 as default.
One pass is enabled by default but wants to be optional:
- Instcombine requires mir_opt_level > 0
Copy propagation is not used by default, but used to be activated by
explicit -Zmir-opt-level=1. It must move one higher to be off by
default:
- CopyPropagation requires mir_opt_level > 1
Deaggregate is not used by default, and used to be on a different level
than CopyPropagation:
- Deaggreate requires mir_opt_level > 2
[LLVM 4.0] Explicitly call constructor of 'llvm::Error'
The implicit constructor has been deleted. We should use
Error::success() instead.
The constructor in the LLVM headers mentions that "success" should be
used instead of the deleted constructor for clarity.
Reinstate while loop in deaggregator pass
A previous commit must have removed the `while let` loop here by
mistake; for each basic block, it should find and deaggregate multiple
statements in their index order, and the `curr` index tracks the
progress through the block.
This fixes both the case of deaggregating statements in separate
basic blocks (preserving `curr` could prevent that) as well
as multiple times in the same block (missing loop prevented that).
The loop was lost in commit bda46c21fe.
Remove the unused top level option by the same name, and retain the
debug option.
Use -Zmir-opt-level=1 as default.
One pass is enabled by default but wants to be optional:
- Instcombine requires mir_opt_level > 0
Copy propagation is not used by default, but used to be activated by
explicit -Zmir-opt-level=1. It must move one higher to be off by
default:
- CopyPropagation requires mir_opt_level > 1
Deaggregate is not used by default, and used to be on a different level
than CopyPropagation:
- Deaggreate requires mir_opt_level > 2
Make configure message re x.py not assume build dir == src dir
Fix#38251 but perhaps not BEST fix for it.
As driveby, fix copyright year in `Makefile.in`
