Calling if-let a combination of if and let is confusing, as some may be led to believe that it's a literal combination, instead of syntactic sugar added to the language as a convenience. What's there to stop someone from thinking if-let is just if and let together?
I do think this article does a good job of implying what's really going on; however, I was only able to notice this after I had begun to understand if/while-let statements, courtesy of the Rust IRC chat.
Basically, this article lacks the clarity and explicitness an inexperienced programmer like me needs in order to understand the contents fully. This is shown by my inability to understand the if-let concept from this page of the Book alone.
I think convenience, sugar, and (if-let != if + let) should all be made mention of in a clear, explicit manner. I lack confidence in my understanding of this issue, so I wrote just enough to hopefully get my thoughts across.
rustbuild: Add sccache support
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.
---
Note that this does not currently change Windows [due to previously written up issues](https://github.com/rust-lang/rust/issues/38119#issuecomment-266631585). Despite that, however, I was curious to get timings for the builds on Travis to see what ranges we're working with. As a result, this is a WIP PR I'm using to gauge build times and such.
make deterministic_hash host-architecture-independent
`DefPath::deterministic_hash` used to call `std:#️⃣:Hash`, which depends on the current architecture in several ways, which would prevent metadata written on one host architecture from being successfully read on another one.
Use a hasher we control instead.
Fixes#38177.
r? @michaelwoerister
Fix unaligned loads in librustc_metadata
Creating a `&[u32]` from an `&[u8]` is not necessarily valid, and crashes
on certain platforms if the data is not well aligned.
rustbuild: Package rust-mingw by default
This fixes the `make dist` step on MinGW to package the `rust-mingw` component
by default. This should hopefully be the last step in fixing nightlies.
The standard implementations of Hasher have architecture-dependent
results when hashing integers. This causes problems when the hashes are
stored within metadata - metadata written by one host architecture can't
be read by another.
To fix that, implement an architecture-independent StableHasher and use
it in all places an architecture-independent hasher is needed.
Fixes#38177.
rustbuild: Add cli option --keep-stage
This option is intended to be used like:
./x.py build --stage 1 --keep-stage 0
Which skips all stage 0 steps, so that stage 1 can be recompiled
directly (even if for example libcore has changes).
This is useful when working on `cfg(not(stage0))` parts of the
libraries or when re-running stage 1 tests in libraries in general.
Fixes#38326
libtest: add --list option to list tests and benchmarks
This option lists all the tests and benchmarks a binary provides without running any of them.
By default the listing is sent to stdout (intended for human consumption), but if `--logfile` is also specified, it is also written there in an easily parsable form.
If filters are specified, they're applied before the output is emitted. The human output will also include a summary unless `-q` is specified.
Redox Support Preview
# Important - This is only a preview of a working `sys::redox`.
Compiling the Redox default distribution with this `libstd` results in a fully functioning distribution. As such, all further changes would be cosmetic or implementing features that have not been used by the default distribution (of which there are only a small number).
I do not expect this to be merged, but would like to discuss how it may be improved and get feedback.
There are a few `unimplemented!()` - `cloexec` for example. I have documented them below. These would be resolved before desiring a merge.
There are also issues with how the Redox syscall library is called - currently I am using a re-export in `libc` but that probably would not be desired.
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.
This option lists all the tests and benchmarks a binary provides. By default the listing
is sent to stdout, but if --logfile is also specified, it is written there.
If filters are specified, they're applied before the output is emitted.
[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.
This option is intended to be used like:
./x.py build --stage 1 --keep-stage 0
Which skips all stage 0 steps, so that stage 1 can be recompiled
directly (even if for example libcore has changes).
This is useful when working on `cfg(not(stage0))` parts of the
libraries, or when re-running stage 1 tests in libraries in general.
