Incrementing the `Archive::child_iterator` fetches and validates the next child.
This can trigger an error, which we previously checked on the *next* call to `LLVMRustArchiveIteratorNext()`.
This means we ignore the last error if we stop iterating halfway through.
This is harmless (we don't access the child, after all) but LLVM 4.0 calls `abort()` if *any* error goes unchecked, even a success value.
This means that basically any rustc invocation that opens an archive and searches through it would die.
The solution implemented here is to change the order of operations, such that
advancing the iterator and fetching the newly-validated iterator happens in the same `Next()` call.
This keeps the error handling behavior as before but ensures all `Error`s get checked.
This commit relegates all pretty tests to not get run by default and rather get
run as part of an "aux" test suite. This "aux" suite is renamed from the old
"cargotest" suite to just collect tests that don't need to run everywhere but
should at least pass on Unix/Windows.
* Update to ripgrep HEAD because the previous rev would still change the lock
file when `cargo build` was issued.
* Remove `bins` as it depends on OpenSSL on Windows, which won't work on our
bots
* Update rev of tokei to get a rev that doesn't change the lockfile
propagate TIME_DEPTH to the helper threads for -Z time-passes
Currently, the timing measurements for LLVM passes and the like don't come out indented, which messes up `perf.rust-lang.org`.
r? @nrc
travis: Attempt to fix Android flakiness
There's been some flaky runs on Travis where the Android emulator is having
problems staying alive... presumably? For example:
* https://travis-ci.org/rust-lang/rust/jobs/186736745
This commit spawns the emulator in the same way as buildbot with `nohup` to hope
that it goes into the background successfully, followed by a `wait-for-device`
command. I'm not actually sure if this'll fix the problems we're seeing, but I
figure it can't hurt to test out.
In an ongoing effort to optimize the runtime of the Android cross builder this
commit updates the pretty test suites to run only for host platforms, not for
target platforms as well. This means we'll still keep running all the suites but
we'll only run them for configured hosts, not for configured targets. This
notably means that we won't be running these suites on Android or musl targets,
for example.
This commit switches the rustbuild build system to compiling the
compiler twice for a normal bootstrap rather than the historical three
times.
Rust is a bootstrapped language which means that a previous version of
the compiler is used to build the next version of the compiler. Over
time, however, we change many parts of compiler artifacts such as the
metadata format, symbol names, etc. These changes make artifacts from
one compiler incompatible from another compiler. Consequently if a
compiler wants to be able to use some artifacts then it itself must have
compiled the artifacts.
Historically the rustc build system has achieved this by compiling the
compiler three times:
* An older compiler (stage0) is downloaded to kick off the chain.
* This compiler now compiles a new compiler (stage1)
* The stage1 compiler then compiles another compiler (stage2)
* Finally, the stage2 compiler needs libraries to link against, so it
compiles all the libraries again.
This entire process amounts in compiling the compiler three times.
Additionally, this process always guarantees that the Rust source tree
can compile itself because the stage2 compiler (created by a freshly
created compiler) would successfully compile itself again. This
property, ensuring Rust can compile itself, is quite important!
In general, though, this third compilation is not required for general
purpose development on the compiler. The third compiler (stage2) can
reuse the libraries that were created during the second compile. In
other words, the second compilation can produce both a compiler and the
libraries that compiler will use. These artifacts *must* be compatible
due to the way plugins work today anyway, and they were created by the
same source code so they *should* be compatible as well.
So given all that, this commit switches the default build process to
only compile the compiler three times, avoiding this third compilation
by copying artifacts from the previous one. Along the way a new entry in
the Travis matrix was also added to ensure that our full bootstrap can
succeed. This entry does not run tests, though, as it should not be
necessary.
To restore the old behavior of a full bootstrap (three compiles) you can
either pass:
./configure --enable-full-bootstrap
or if you're using config.toml:
[build]
full-bootstrap = true
Overall this will hopefully be an easy 33% win in build times of the
compiler. If we do 33% less work we should be 33% faster! This in turn
should affect cycle times and such on Travis and AppVeyor positively as
well as making it easier to work on the compiler itself.
(Minor typo fix.)
Since the word `i32` starts with a vowel, the indefinite article should use "an", not "a" \[[1](http://www.dictionary.com/browse/an)\]. (Previously there was one instance of "an i32" and two instances of "a i32", so at least something is wrong!) Since I believe that "an" is the correct form, I aligned everything with that.
[10/n] Split constants and functions' arguments into disjoint bodies.
_This is part of a series ([prev](https://github.com/rust-lang/rust/pull/38053) | [next]()) of patches designed to rework rustc into an out-of-order on-demand pipeline model for both better feature support (e.g. [MIR-based](https://github.com/solson/miri) early constant evaluation) and incremental execution of compiler passes (e.g. type-checking), with beneficial consequences to IDE support as well.
If any motivation is unclear, please ask for additional PR description clarifications or code comments._
<hr>
Finishes the signature-body split started in #37918, namely:
* `trait` items are separated just like `impl` items were, for uniformity, closing #37712
* `static`s, `const`s (including associated ones), `enum` discriminants and array lengths get bodies
* even the count in "repeat expressions", i.e. `n` in `[x; n]`, which fixes#24414
* arguments' patterns are moved to the bodies, with the types staying in `FnDecl`
* `&self` now desugars to `self: &Self` instead of `self: &_` (similarly for other `self` forms)
* `astconv`'s and metadata's (for rustdoc) informative uses are explicitly ignored for the purposes of the dep graph. this could be fixed in the future by hashing the exact information being extracted about the arguments as opposed to generating a dependency on *the whole body*
Resetting the terminal should first try `sgr0` (as per the comment), not
`sg0` which I believe to be a typo.
This will at least fix rustc output in Emacs terminals (e.g., ansi-term)
with `TERM=eterm-color` which does not provide the next fallback `sgr`. In
such a terminal, the final fallback `op` (`\e[39;49`) is used which
resets only colors, not all attributes. This causes all text to be
printed in bold from the first string printed in bold by rustc onwards,
including the terminal prompt and the output from all following commands.
The typo seems to have been introduced by #29999
A new option is introduced under the `[llvm]` section of `config.toml`,
`targets`, for overriding the list of LLVM targets to build support for.
The option is passed through to LLVM configure script. Also notes are
added about the implications of (ab)using the option; since the default
is not changed, and users of the option are expected to know what
they're doing anyway (as every porter should), the impact should be
minimal.
Fixes#38200.
rustbuild: Hotfix to unbreak nightly
Fixes an oversight unnoticed in #38468 that eventually broke nightly packaging. I didn't realize this until some moments ago, when I finally found out the failure is actually deterministic. Many apologies for eating 3 nightlies during the holidays.
r? @alexcrichton
Fix argument handling on Redox
After switching the start code to be handled in libc, we are no longer passing in slices as arguments into the libstd main function. This means that handling had to be rewritten to match the unix way of doing things.
Additional commits on this branch are going to be merged in this PR: https://github.com/rust-lang/rust/pull/38577#issuecomment-269138394
Refactor mir::dataflow: remove Ctxt associated type from BitDenotation trait
Refactor mir::dataflow: remove Ctxt associated type from BitDenotation trait
I no longer remember why I needed this (or thought I did). The way
that the `BitDenotation` is passed around in all existing use cases
(and planned future ones), the thing that were in the `Ctxt` can just
be part of `Self` instead.
(I think ariel had been pushing me to do this back when I first put in
this infrastructure; it took me a while to see how much of pain the
`Ctxt` was causing.)
On Android we only have one test thread for supposed problems with concurrency
and the remote debugger. Not all of our suites require one concurrency, however,
and suites like compile-fail or pretty can be much faster if they're
parallelized on Travis.
This commit only sets the test threads to one on Android for suites which
actually run code, and other suites aren't tampered with.
Teach `rustdoc --test` about `--sysroot`, pass it when testing rust
This permits rustdoc tests to work in stage0.
Logical continuation of #36586.
Snippet from https://github.com/rust-lang/rust/issues/38575#issuecomment-269090724:
> it should actually be possible to run all the libstd tests immediately after creating std of stage0-out - there's no reason to build librustc at all if you've just made a change to (for example) libcollections, `./x.py test src/libcollections --stage 0 -v --incremental` should just work
This PR makes it so (or appears to in my testing).
r? @alexcrichton
Add a min_atomic_width target option, like max_atomic_width
Rationale: some ISAs, e.g. OR1K, do not have atomic instructions
for byte and halfword access, and at the same time do not have
a fixed endianness, which makes it unreasonable to implement these
through word-sized atomic accesses.
`arr` is the actual list of targets participating in steps construction,
but due to #38468 the hosts array now consists of only the build triple
for the `dist` steps, hence all non-build-triple targets are lost for
the host-only rules.
Fix this by using the original non-shadowed hosts array in `arr`
calculation. This should unbreak the nightly packaging process.
Fixes#38637.
The comment touched, as originally written, only concerned itself with
the `test` steps. However, since #38468 the `arr` variable actually has
gained an indirect relationship with the `dist` steps too. The comment
failed to convey the extra meaning, contributing to the misunderstanding
which eventually lead to #38637. Fix that by moving the comment into the
right place near the relevant condition, and properly documenting
`arr`'s purpose.
