We now do two phases. First, we gather up the list of candidates with
suitable return types and extract their names. Then we filter those to
see which are applicable and we return that.
It might be nice to do the "filter by return type" as a second step,
but this is ok for now.
I updated the beta compiler used to bootstrap the master branch in #38438 with
the intention of fixing Travis OSX linkage issues but I mistakenly forgot that
the PR only updated rustc, not Cargo itself. Cargo has a new release process
with downloads in a different location, so this commit updates rustbuild to
download from this new location by tracking revisions instead of Cargo nightly
dates.
add preliminary support for incremental compilation to rustbuild.py
This implements the integration described in #37929. It requires the use of a local nightly as your bootstrap compiler. The setup is described in `src/bootstrap/README.md`.
This does NOT implement the "copy stage0 libs to stage1" optimization described in #37929, just because that seems orthogonal to me.
In local testing, I do not yet see any incremental re-use when building rustc. I'm not sure why that is, more investigation needed.
(For these reasons, this is not marked as fixing the relevant issue.)
r? @alexcrichton -- I included one random cleanup (`Step::noop()`) that turned out to not be especially relevant. Feel free to tell me you liked it better the old way.
This commit configures local sccache directory to get used if you're running
builds locally to enjoy the benefits of caching when running inside the
containers.
Recently the Cargo revision running on cargotest was updated in #38051, and the
updated version of Cargo pulls in the openssl-sys 0.9 crate instead of the old
openssl-sys 0.7 crate. The 0.9 release of openssl-sys has slightly different
requirements and logic for detecting OpenSSL, namely it requires `pkg-config` to
be present on Linux typically.
This commit fixes this problem by installing pkg-config in the cargotest
container that's running on the bots. This in turn should hopefully fix the
build script and allow it to find the already-installed local OpenSSL libraries.
rustbuild: Fix `copy` helper with existing files
This erroneously truncated files when the destination already existed and was an
existing hard link to the source. This in turn caused weird bugs!
Closes#37745
Use exec for the wrapper on UNIXes
This not only avoids the small – and unnecessary – constant overhead for each compiler invocation,
but also helps somewhat by only having “correct” rustc processes to look for in `/proc/`.
This also makes the wrapper behave effectively as a regular exec wrapper its intended to be.
I also took liberty to change the fallback error code from `1` to `0xfe` (now only relevant on windows) so that when people complain about “compiler exited with code 254”, its obvious where the issue lies (wrapper losing the exit code somehow).
r? @alexcrichton
Update beta bootstrap compiler
The current beta that rustc is bootstrapping from contains a bug in Cargo that
erroneously links to OpenSSL in /usr/local, but this is fixed in the most recent
1.14 beta, so let's use that.
tidy features: use 2-parameter form of internal try macro for open err
This tiny patch merely applies @bluss's suggestion for how to get a more
informative error message when the feature check can't open a file, a
matter that had briefly annoyed the present author, leading to the
filing of #38417.
Resolves#38417.
rustc: Disable NEON on armv7 android.
We thought Google's ABI for arvm7 required neon, but it is
currently optional, perhaps because there is a significant
population of Tegra 2 devices still in use.
This turns off neon code generation outside #[target-feature]
blocks just like we do on armv7-unknown-linux-gnu, but unlike
most other armv7 targets. LLVM defaults to +neon for this target,
so an explicit disable is necessary.
See https://developer.android.com/ndk/guides/abis.html#v7a
for instruction set extension requirements.
Closes#38402.
llvm: backport r280651
fixes#38406
r? @alexcrichton
(I'm secretly hoping this will error in the same way as #38314. That would sort of confirm that the problem is OOM and not enabling the SPARC backend)
Don't perform span mangling when building field/tup access nodes
There are no guarantees that the two spans used to create the new one
come from the same place or are even valid.
Fixes#36081.
