test: Forcibly remove MAKEFLAGS in compiletest
When executing run-make tests we run a risk of leaking the `MAKEFLAGS`
environment variable if `./x.py` itself was called from `make` (aka `make check
-j3` as the OSX bots do). We may then leak accidentally fds into the child
process and trick it into thinking it's got a jobserver!
Hopefully addresses [this] spurious failure
[this]: https://github.com/rust-lang/rust/pull/48295#issuecomment-372134717
When executing run-make tests we run a risk of leaking the `MAKEFLAGS`
environment variable if `./x.py` itself was called from `make` (aka `make check
-j3` as the OSX bots do). We may then leak accidentally fds into the child
process and trick it into thinking it's got a jobserver!
Hopefully addresses [this] spurious failure
[this]: https://github.com/rust-lang/rust/pull/48295#issuecomment-372134717
Required moving all fulldeps tests depending on `rand` to different locations as
now there's multiple `rand` crates that can't be implicitly linked against.
Remove ONLY_BUILD and ONLY_BUILD_TARGETS
Primarily removes `ONLY_BUILD` and `ONLY_BUILD_TARGETS`. These aren't actually needed in the new system since we can simply not take the relevant `host` and `target` fields if we don't want to run with them in `Step::make_run`.
This PR also includes a few other commits which generally clean up the state of rustbuild, but are not related to the `Step` changes.
The code for several of the core traits doesn't use hygenic macros.
This isn't a problem, except for the Debug trait, which is the only
one that uses a variable, named "builder".
Variables can't share names with unit structs, so attempting to
[derive(Debug)] on any type while a unit struct with the name
"builder" was in scope would result in an error.
This commit just changes the name of the variable to
"__debug_trait_builder", because I couldn't figure out how to get a
list of all unit structs in-scope from within the derive expansion
function. If someone wants to have a unit struct with
the exact name "__debug_trait_builder", they'll just have to do it
without a [derive(Debug)].
Some minor CI changes
1. On macOS, ensure crash log printing won't error, and only real crash logs are printed. This may avoid the `find` process exiting abnormally and truncated the Travis log (I guess).
2. Print `/proc/cpuinfo` and `/proc/meminfo`. To determine if there's any variation in the reported clock rate between jobs.
travis: Upgrade OSX builders
This upgrades the OSX builders to the `xcode9.3-moar` image which has 3 cores as
opposed to the 2 that our builders currently have. Should help make those OSX
builds a bit speedier!
(Meanwhile, a couple of parse-fail tests are moved to UI tests so that
the reader can see the new output, and an existing UI test is given a
more evocative name.)
Use free regions when determining self type in `compare_impl_method`
The ExplicitSelf::determine function expects to be able to compare regions. However, when the compare_self_type error reporting code runs we haven't resolved bound regions yet. Thus we replace them with free regions first. Fixes#48276
Add relro-level tests
The `relro-level` debugging flag was added in #43170 which was merged in July 2017. This PR moves this flag to be a proper codegen flag.
rustbuild: Pass `-j1` to OpenSSL `make install`
We explicitly do this when compiling OpenSSL itself due to weird racy issues in
its build system, and now we've started seeing issues in the `make install` step
so let's try and see what ratcheting down the parallelism does here...
We explicitly do this when compiling OpenSSL itself due to weird racy issues in
its build system, and now we've started seeing issues in the `make install` step
so let's try and see what ratcheting down the parallelism does here...
travis: Upgrade dist builders for OSX
This commit upgrades the dist builders for OSX to Travis's new `xcode9.3-moar`
image which has 3 cores available to it instead of 2. This should help us
provide speedier builds on OSX and hit timeouts less in theory!
Note that historically the dist builders for OSX have been a different version
than the ones that are running tests. I had forgotten why this was the case and
digging around brought up 307615567 where apparently Xcode 8 wasn't able to
compile LLVM with `MACOSX_DEPLOYMENT_TARGET=10.7` which we desired. On a whim I
gave this PR a spin and it [looks like][green] this has since been fixed (maybe
in LLVM?). In any case those green builds should hopefully mean that we can
safely upgrade and get faster infrastructure to boot.
This commit also includes an upgrade of OpenSSL. This is not done for security
reasons but rather build system reasons. Originally builds with the new image
[did not succeed][red] due to weird build failures in OpenSSL, but upgrading
seems to have made the spurious errors go away to here's to also hoping that's
fixed!
[green]: https://travis-ci.org/rust-lang/rust/builds/351353412
[red]: https://travis-ci.org/rust-lang/rust/builds/350969248
This commit upgrades the dist builders for OSX to Travis's new `xcode9.3-moar`
image which has 3 cores available to it instead of 2. This should help us
provide speedier builds on OSX and hit timeouts less in theory!
Note that historically the dist builders for OSX have been a different version
than the ones that are running tests. I had forgotten why this was the case and
digging around brought up 307615567 where apparently Xcode 8 wasn't able to
compile LLVM with `MACOSX_DEPLOYMENT_TARGET=10.7` which we desired. On a whim I
gave this PR a spin and it [looks like][green] this has since been fixed (maybe
in LLVM?). In any case those green builds should hopefully mean that we can
safely upgrade and get faster infrastructure to boot.
This commit also includes an upgrade of OpenSSL. This is not done for security
reasons but rather build system reasons. Originally builds with the new image
[did not succeed][red] due to weird build failures in OpenSSL, but upgrading
seems to have made the spurious errors go away to here's to also hoping that's
fixed!
[green]: https://travis-ci.org/rust-lang/rust/builds/351353412
[red]: https://travis-ci.org/rust-lang/rust/builds/350969248
rustbuild: Fix MSBuild location of `llvm-config.exe`
For LLD integration the path to `llvm-config` needed to change to inside the
build directory itself (for whatever reason) but the build directory is
different on MSBuild than it is on `ninja` for MSVC builds, so the path to
`llvm-config.exe` was actually wrong and not working!
This commit removes the `Build::llvm_config` function in favor of the source of
truth, the `Llvm` build step itself. The build step was then updated to find the
right build directory for MSBuild as well as `ninja` for where `llvm-config.exe`
is located.
Closes#48749
See #48431 for discussion as to why this was necessary and what we hoped to
accomplish. A brief summary:
- the first implementation of 2-phase borrows was hard to limit in the way we
wanted. That is, it was too good at accepting all 2-phase borrows rather than
just autorefs =)
- Numerous diagnostic regressions were introduced by 2-phase borrow support
which were difficult to fix
The new output format is perhaps a little more readable. As a bonus, we get
labels on the outgoing edges to more easily corroborate the dataflow with the
plain MIR graphviz output.
For LLD integration the path to `llvm-config` needed to change to inside the
build directory itself (for whatever reason) but the build directory is
different on MSBuild than it is on `ninja` for MSVC builds, so the path to
`llvm-config.exe` was actually wrong and not working!
This commit removes the `Build::llvm_config` function in favor of the source of
truth, the `Llvm` build step itself. The build step was then updated to find the
right build directory for MSBuild as well as `ninja` for where `llvm-config.exe`
is located.
Closes#48749
Warn about ignored generic bounds in `for`
This adds a new lint to fix#42181. For consistency and to avoid code duplication, I also moved the existing "bounds in type aliases are ignored" here.
Questions to the reviewer:
* Is it okay to just remove a diagnostic error code like this? Should I instead keep the warning about type aliases where it is? The old code provided a detailed explanation of what's going on when asked, that information is now lost. On the other hand, `span_warn!` seems deprecated (after this patch, it has exactly one user left!).
* Did I miss any syntactic construct that can appear as `for` in the surface syntax? I covered function types (`for<'a> fn(...)`), generic traits (`for <'a> Fn(...)`, can appear both as bounds as as trait objects) and bounds (`for<'a> F: ...`).
* For the sake of backwards compatibility, this adds a warning, not an error. @nikomatsakis suggested an error in https://github.com/rust-lang/rust/issues/42181#issuecomment-306924389, but I feel that can only happen in a new epoch -- right?
Cc @eddyb
