The `--android-cross-path` has been deprecated for some time now, we should use
`CFG_ARM_LINUX_ANDROIDEABI_NDK` instead.
Ideally this would use the right triple, but we're only testing ARM for now.
Sanity check Python on OSX for LLDB tests
Two primary changes:
* Don't get past the configure stage if `python` isn't coming from `/usr/bin`
* Call `debugger.Terminate()` to prevent segfaults on newer versions of LLDB.
Closes#32994
This uncovered a lot of bugs in compiletest and also some shortcomings
of our existing JSON output. We had to add information to the JSON
output, such as suggested text and macro backtraces. We also had to fix
various bugs in the existing tests.
Joint work with jntrnr.
Compute `target_feature` from LLVM
This is a work-in-progress fix for #31662.
The logic that computes the target features from the command line has been replaced with queries to the `TargetMachine`.
This commit removes all infrastructure from the repository for our so-called
snapshots to instead bootstrap the compiler from stable releases. Bootstrapping
from a previously stable release is a long-desired feature of distros because
they're not fans of downloading binary stage0 blobs from us. Additionally, this
makes our own CI easier as we can decommission all of the snapshot builders and
start having a regular cadence to when we update the stage0 compiler.
A new `src/etc/get-stage0.py` script was added which shares some code with
`src/bootstrap/bootstrap.py` to read a new file, `src/stage0.txt`, which lists
the current stage0 compiler as well as cargo that we bootstrap from. This script
will download the relevant `rustc` package an unpack it into `$target/stage0` as
we do today.
One problem of bootstrapping from stable releases is that we're not able to
compile unstable code (e.g. all the `#![feature]` directives in libcore/libstd).
To overcome this we employ two strategies:
* The bootstrap key of the previous compiler is hardcoded into `src/stage0.txt`
(enabled as a result of #32731) and exported by the build system. This enables
nightly features in the compiler we download.
* The standard library and compiler are pinned to a specific stage0, which
doesn't change, so we're guaranteed that we'll continue compiling as we start
from a known fixed source.
The process for making a release will also need to be tweaked now to continue to
cadence of bootstrapping from the previous release. This process looks like:
1. Merge `beta` to `stable`
2. Produce a new stable compiler.
3. Change `master` to bootstrap from this new stable compiler.
4. Merge `master` to `beta`
5. Produce a new beta compiler
6. Change `master` to bootstrap from this new beta compiler.
Step 3 above should involve very few changes as `master` was previously
bootstrapping from `beta` which is the same as `stable` at that point in time.
Step 6, however, is where we benefit from removing lots of `#[cfg(stage0)]` and
get to use new features. This also shouldn't slow the release too much as steps
1-5 requires little work other than waiting and step 6 just needs to happen at
some point during a release cycle, it's not time sensitive.
Closes#29555Closes#29557
This commit adds support in rustbuild for running all of the compiletest test
suites as part of `make check`. The `compiletest` program was moved to
`src/tools` (like `rustbook` and others) and is now just compiled like any other
old tool. Each test suite has a pretty standard set of dependencies and just
tweaks various parameters to the final compiletest executable.
Note that full support is lacking in terms of:
* Once a test suite has passed, that's not remembered. When a test suite is
requested to be run, it's always run.
* The arguments to compiletest probably don't work for every possible
combination of platforms and testing environments just yet. There will likely
need to be future updates to tweak various pieces here and there.
* Cross compiled test suites probably don't work just yet, support for that will
come in a follow-up patch.
This verifies that the crates listed in the `[dependencies]` section of
`Cargo.toml` are a subset of the crates listed in `lib.rs` for our in-tree
crates. This should help ensure that when we refactor crates over time we keep
these dependency lists in sync.
This commit rewrites all of the tidy checks we have, namely:
* featureck
* errorck
* tidy
* binaries
into Rust under a new `tidy` tool inside of the `src/tools` directory. This at
the same time deletes all the corresponding Python tidy checks so we can be sure
to only have one source of truth for all the tidy checks.
cc #31590
mk: Hardcode the bootstrap key for each release
Starting with the 1.10.0 release we would like to bootstrap all compilers from
the previous stable release. For example the 1.10.0 compiler should bootstrap
from the literal 1.9.0 release artifacts. To do this, however, we need a way to
enable unstable features temporarily in a stable compiler (as the released
compiler is stable), but it turns out we already have a way to do that!
At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable
value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY`
environment variable is set to this value, then the compiler is allowed to
"cheat" and use unstable features.
This method of choosing the bootstrap key, however, is problematic for the
intention of bootstrapping from the previous release. Each time a 1.9.0 compiler
is created, a new bootstrap key will be selected. That means that the 1.10.0
compiler will only compile from *our* literal release artifacts. Instead
distributions would like to bootstrap from their own compilers, so instead we
simply hardcode the bootstrap key for each release.
This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release
string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where
they are compiled, will have the same bootstrap key. Additionally we won't need
to keep updating this as it'll be based on the release number anyway.
Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources
(the `master` branch at that time) to bootstrap from that release using this
hard-coded bootstrap key. We will likely just hardcode into the makefiles what
the previous bootstrap key was and we'll change that whenever the stage0
compiler is updated.
Starting with the 1.10.0 release we would like to bootstrap all compilers from
the previous stable release. For example the 1.10.0 compiler should bootstrap
from the literal 1.9.0 release artifacts. To do this, however, we need a way to
enable unstable features temporarily in a stable compiler (as the released
compiler is stable), but it turns out we already have a way to do that!
At compile time the configure script selects a `CFG_BOOTSTRAP_KEY` variable
value and then exports it into the makefiles. If the `RUSTC_BOOTSTRAP_KEY`
environment variable is set to this value, then the compiler is allowed to
"cheat" and use unstable features.
This method of choosing the bootstrap key, however, is problematic for the
intention of bootstrapping from the previous release. Each time a 1.9.0 compiler
is created, a new bootstrap key will be selected. That means that the 1.10.0
compiler will only compile from *our* literal release artifacts. Instead
distributions would like to bootstrap from their own compilers, so instead we
simply hardcode the bootstrap key for each release.
This patch uses the same `CFG_FILENAME_EXTRA` value (a hash of the release
string) as the bootstrap key. Consequently all 1.9.0 compilers, no matter where
they are compiled, will have the same bootstrap key. Additionally we won't need
to keep updating this as it'll be based on the release number anyway.
Once the 1.9.0 beta has been created, we can update the 1.10.0 nightly sources
(the `master` branch at that time) to bootstrap from that release using this
hard-coded bootstrap key. We will likely just hardcode into the makefiles what
the previous bootstrap key was and we'll change that whenever the stage0
compiler is updated.
Our `codegen` test suite requires the LLVM `FileCheck` utility but unfortunately
this isn't always available in all custom LLVM roots (e.g. those specified via
`--llvm-root`). This commit adds a `./configure` option called
`--disable-codegen-tests` which will manually disable running these tests. In
the case that this option is passed we can forgo the need for the `FileCheck`
executable. Note that we still require `FileCheck` by default as we will attempt
to run these tests.
Closes#28667
mk: A few build fixes for i586-pc-windows-msvc
Detect the triple in the configure script for probing MSVC shenanigans and also
be sure to use `llvm-config` from the build host and not the target when
configuring compiler-rt.
mk: Fix cross-host builds
The change in b20e748 had the unintended consequence of breaking cross-host
builds as we apparently relied on the incorrect definition of this variable in
the makefiles. That change, however, was required to get tests passing so we
couldn't just revert it.
This commit fixes the underlying bug by leaving the "more correct" definition of
`LD_LIBRARY_PATH_ENV_TARGETDIR` (also fixing it with a hardcoded reference to
`CFG_BUILD`) and updating the `RPATH_VAR` definition below. Turned out we
already had special-casing logic for passing `--cfg stage1` during the
well-we-print-this-as-stage0 build of a cross-host. That logic was just updated
to pull from a different variable as opposed to relying on the definition of
that variable to accommodate this.
Closes#32568
Detect the triple in the configure script for probing MSVC shenanigans and also
be sure to use `llvm-config` from the build host and not the target when
configuring compiler-rt.
The change in b20e748 had the unintended consequence of breaking cross-host
builds as we apparently relied on the incorrect definition of this variable in
the makefiles. That change, however, was required to get tests passing so we
couldn't just revert it.
This commit fixes the underlying bug by leaving the "more correct" definition of
`LD_LIBRARY_PATH_ENV_TARGETDIR` (also fixing it with a hardcoded reference to
`CFG_BUILD`) and updating the `RPATH_VAR` definition below. Turned out we
already had special-casing logic for passing `--cfg stage1` during the
well-we-print-this-as-stage0 build of a cross-host. That logic was just updated
to pull from a different variable as opposed to relying on the definition of
that variable to accommodate this.
Closes#32568
This should re-enable all external builds of crates with the same name. Right
now Cargo doesn't pass `-C metadata` for the top-level library being compiled,
so if that library is called `libc`, for example, then it won't be able to link
to the standard library which *also* has a `libc` library compiled without `-C
metadata`. This can result in naming conflicts which need to be resolved.
By passing `-C metadata` to the in-tree crates we ship it should add some extra
salt to all symbol names to ensure that they don't collide.
emit (via debug!) scary message from `fn borrowck_mir` until basic
prototype is in place.
Gather children of move paths and set their kill bits in
dataflow. (Each node has a link to the child that is first among its
siblings.)
Hooked in libgraphviz based rendering, including of borrowck dataflow
state.
doing this well required some refactoring of the code, so I cleaned it
up more generally (adding comments to explain what its trying to do
and how it is doing it).
Update: this newer version addresses most review comments (at least
the ones that were largely mechanical changes), but I left the more
interesting revisions to separate followup commits (in this same PR).
typestrong const integers
~~It would be great if someone could run crater on this PR, as this has a high danger of breaking valid code~~ Crater ran. Good to go.
----
So this PR does a few things:
1. ~~const eval array values when const evaluating an array expression~~
2. ~~const eval repeat value when const evaluating a repeat expression~~
3. ~~const eval all struct and tuple fields when evaluating a struct/tuple expression~~
4. remove the `ConstVal::Int` and `ConstVal::Uint` variants and replace them with a single enum (`ConstInt`) which has variants for all integral types
* `usize`/`isize` are also enums with variants for 32 and 64 bit. At creation and various usage steps there are assertions in place checking if the target bitwidth matches with the chosen enum variant
5. enum discriminants (`ty::Disr`) are now `ConstInt`
6. trans has its own `Disr` type now (newtype around `u64`)
This obviously can't be done without breaking changes (the ones that are noticable in stable)
We could probably write lints that find those situations and error on it for a cycle or two. But then again, those situations are rare and really bugs imo anyway:
```rust
let v10 = 10 as i8;
let v4 = 4 as isize;
assert_eq!(v10 << v4 as usize, 160 as i8);
```
stops compiling because 160 is not a valid i8
```rust
struct S<T, S> {
a: T,
b: u8,
c: S
}
let s = S { a: 0xff_ff_ff_ffu32, b: 1, c: 0xaa_aa_aa_aa as i32 };
```
stops compiling because `0xaa_aa_aa_aa` is not a valid i32
----
cc @eddyb @pnkfelix
related: https://github.com/rust-lang/rfcs/issues/1071
Add a link validator to rustbuild
This commit was originally targeted at just adding a link checking script to the rustbuild system. This ended up snowballing a bit to extend rustbuild to be amenable to various tools we have as part of the build system in general.
There's a new `src/tools` directory which has a number of scripts/programs that are purely intended to be used as part of the build system and CI of this repository. This is currently inhabited by rustbook, the error index generator, and a new linkchecker script added as part of this PR. I suspect that more tools like compiletest, tidy scripts, snapshot scripts, etc will migrate their way into this directory over time.
The commit which adds the error index generator shows the steps necessary to add new tools to the build system, namely:
1. New steps are defined for building the tool and running the tool
2. The dependencies are configured
3. The steps are implemented
In terms of the link checker, these commits do a few things:
* A new `src/tools/linkchecker` script is added. This will read an entire documentation tree looking for broken relative links (HTTP links aren't followed yet).
* A large number of broken links throughout the documentation were fixed. Many of these were just broken when viewed from core as opposed to std, but were easily fixed.
* A few rustdoc bugs here and there were fixed
rustc: Add an i586-pc-windows-msvc target
Similarly to #31629 where an i586-unknown-linux-gnu target was added, there is
sometimes a desire to compile for x86 Windows as well where SSE2 is disabled.
This commit mirrors the i586-unknown-linux-gnu target and simply adds a variant
for Windows as well.
This is motivated by a recent [Gecko bug][ff] where crashes were seen on 32-bit
Windows due to users having CPUs that don't support SSE2 instructions. It was
requested that we could have non-SSE2 builds of the standard library available
so they could continue to use vanilla releases and nightlies.
[ff]: https://bugzilla.mozilla.org/show_bug.cgi?id=1253202
mk: Distribute fewer TARGET_CRATES
Right now everything in TARGET_CRATES is built by default for all non-fulldeps
tests and is distributed by default for all target standard library packages.
Currenly this includes a number of unstable crates which are rarely used such as
`graphviz` and `rbml`>
This commit trims down the set of `TARGET_CRATES`, moves a number of tests to
`*-fulldeps` as a result, and trims down the dependencies of libtest so we can
distribute fewer crates in the `rust-std` packages.
Right now everything in TARGET_CRATES is built by default for all non-fulldeps
tests and is distributed by default for all target standard library packages.
Currenly this includes a number of unstable crates which are rarely used such as
`graphviz` and `rbml`>
This commit trims down the set of `TARGET_CRATES`, moves a number of tests to
`*-fulldeps` as a result, and trims down the dependencies of libtest so we can
distribute fewer crates in the `rust-std` packages.
Adding -Wno-error is more reliable and simple than trying to modify existing
flags. We've been using this in Debian already for the past few releases.
Making this change also encourages future maintainers towards "best practises".
Also take the opportunity to use the same method at all places in the file.
Adding -Wno-error is more reliable and simple than trying to modify existing
flags. We've been using this in Debian already for the past few releases.
Making this change also encourages future maintainers towards "best practises".
Also take the opportunity to use the same method at all places in the file.
Similarly to #31629 where an i586-unknown-linux-gnu target was added, there is
sometimes a desire to compile for x86 Windows as well where SSE2 is disabled.
This commit mirrors the i586-unknown-linux-gnu target and simply adds a variant
for Windows as well.
This is motivated by a recent [Gecko bug][ff] where crashes were seen on 32-bit
Windows due to users having CPUs that don't support SSE2 instructions. It was
requested that we could have non-SSE2 builds of the standard library available
so they could continue to use vanilla releases and nightlies.
[ff]: https://bugzilla.mozilla.org/show_bug.cgi?id=1253202
The `--disable-jemalloc` configure option has a failure mode where it will
create a distribution that is not compatible with other compilers. For example
the nightly for Linux will assume that it will link to jemalloc by default as
an allocator for executable crates. If, however, a standard library is used
which was built via `./configure --disable-jemalloc` then this will fail
because the jemalloc crate wasn't built.
While this seems somewhat reasonable as a niche situation, the same mechanism is
used for disabling jemalloc for platforms that just don't support it. For
example if the rumprun target is compiled then the sibiling Linux target *also*
doesn't have jemalloc. This is currently a problem for our cross-build nightlies
which build many targets. If rumprun is also built, it will disable jemalloc for
all targets, which isn't desired.
This commit moves the platform-specific disabling of jemalloc as hardcoded logic
into the makefiles that is scoped per-platform. This way when configuring
multiple targets **without the `--disable-jemalloc` option specified** all
targets will get jemalloc as they should.
The `--disable-jemalloc` configure option has a failure mode where it will
create a distribution that is not compatible with other compilers. For example
the nightly for Linux will assume that it will link to jemalloc by default as
an allocator for executable crates. If, however, a standard library is used
which was built via `./configure --disable-jemalloc` then this will fail
because the jemalloc crate wasn't built.
While this seems somewhat reasonable as a niche situation, the same mechanism is
used for disabling jemalloc for platforms that just don't support it. For
example if the rumprun target is compiled then the sibiling Linux target *also*
doesn't have jemalloc. This is currently a problem for our cross-build nightlies
which build many targets. If rumprun is also built, it will disable jemalloc for
all targets, which isn't desired.
This commit moves the platform-specific disabling of jemalloc as hardcoded logic
into the makefiles that is scoped per-platform. This way when configuring
multiple targets **without the `--disable-jemalloc` option specified** all
targets will get jemalloc as they should.
You can now group tests into directories like `run-pass/borrowck` or `compile-fail/borrowck`. By default, all `.rs` files within any directory are considered tests: to ignore some directory, create a placeholder file called `compiletest-ignore-dir` (I had to do this for several existing directories).
r? @alexcrichton
cc @brson
Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf`
target which is to map it to an armv6 architecture.
Closes#31787
Right now the compiler's we're using actually default to armv7/thumb2 I believe,
so this should help push them back to what the arm-unknown-linux-* targets are
for. This at least matches that clang does for the `arm-unknown-linux-gnueabihf`
target which is to map it to an armv6 architecture.
Closes#31787
use CXX value found at configure time inside run-make tests.
it permits OpenBSD to pass llvm-module-pass test (which use CXX
variable).
r? @alexcrichton
This is because the tool compiler passes the name of the tool
as a command line `--cfg`. The improved session config parser
is stricter and no longer permits invalid meta items (such as
"error-index-generator").
Now that we properly only link in jemalloc when building executables, we have
far less to worry about in terms of polluting the global namespace with the
`free` and `malloc` symbols on Linux. This commit will primarily allow LLVM to
use jemalloc so the compiler will only be using one allocator overall.
Locally this took compile time for libsyntax from 95 seconds to 89 (a 6%
improvement).
r? @brson
cc @alexcrichton
I still need to add error code explanation test with this, but I can't figure out a way to generate the `.md` files in order to test example source codes.
Will fix#27328.
When building with Cargo we need to detect `feature = "jemalloc"` to enable
jemalloc, so propagate this same change to the build system to pass the right
`--cfg` argument.
Backtraces, and the compilation of libbacktrace for asmjs, are disabled.
This port doesn't use jemalloc so, like pnacl, it disables jemalloc *for all targets*
in the configure file.
It disables stack protection.
Without this patch, `compiler-rt` fails to build when the `CFLAGS` environment variable contains a `-Werror=*` flag (for example `-Werror=format-security`).
The build system was removing only the `-Werror` part from the flag, thus passing an unrecognized `=*` (for example `=format-security`) argument to gcc.
This pull request adds support for [Illumos](http://illumos.org/)-based operating systems: SmartOS, OpenIndiana, and others. For now it's x86-64 only, as I'm not sure if 32-bit installations are widespread. This PR is based on #28589 by @potatosalad, and also closes#21000, #25845, and #25846.
Required changes in libc are already merged: https://github.com/rust-lang-nursery/libc/pull/138
Here's a snapshot required to build a stage0 compiler:
https://s3-eu-west-1.amazonaws.com/nbaksalyar/rustc-sunos-snapshot.tar.gz
It passes all checks from `make check`.
There are some changes I'm not quite sure about, e.g. macro usage in `src/libstd/num/f64.rs` and `DirEntry` structure in `src/libstd/sys/unix/fs.rs`, so any comments on how to rewrite it better would be greatly appreciated.
Also, LLVM configure script might need to be patched to build it successfully, or a pre-built libLLVM should be used. Some details can be found here: https://llvm.org/bugs/show_bug.cgi?id=25409
Thanks!
r? @brson
Currently any compilation to MIPS spits out the warning:
'generic' is not a recognized processor for this target (ignoring processor)
Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
This target covers MIPS devices that run the trunk version of OpenWRT.
The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.
As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.
r? @alexcrichton
I don't believe these test cases have served any purpose in years.
The shootout benchmarks are now upstreamed. A new benchmark suite
should rather be maintained out of tree.
r? @nikomatsakis
Currently any compilation to MIPS spits out the warning:
'generic' is not a recognized processor for this target (ignoring processor)
Doesn't make for a great user experience! We don't encounter this in the normal
bootstrap because the cpu/feature set are set by the makefiles. Instead let's
just propagate these to the defaults for the entire target all the time (still
overridable from the command line) and prevent warnings from being emitted by
default.
These commits perform a few high-level changes with the goal of enabling i686 MSVC unwinding:
* LLVM is upgraded to pick up the new exception handling instructions and intrinsics for MSVC. This puts us somewhere along the 3.8 branch, but we should still be compatible with LLVM 3.7 for non-MSVC targets.
* All unwinding for MSVC targets (both 32 and 64-bit) are implemented in terms of this new LLVM support. I would like to also extend this to Windows GNU targets to drop the runtime dependencies we have on MinGW, but I'd like to land this first.
* Some tests were fixed up for i686 MSVC here and there where necessary. The full test suite should be passing now for that target.
In terms of landing this I plan to have this go through first, then verify that i686 MSVC works, then I'll enable `make check` on the bots for that target instead of just `make` as-is today.
Closes#25869
This target covers MIPS devices that run the trunk version of OpenWRT.
The x86_64-unknown-linux-musl target always links statically to C libraries. For
the mips(el)-unknown-linux-musl target, we opt for dynamic linking (like most of
other targets do) to keep binary size down.
As for the C compiler flags used in the build system, we use the same flags used
for the mips(el)-unknown-linux-gnu target.
I don't believe these test cases have served any purpose in years.
The shootout benchmarks are now upstreamed. A new benchmark suite
should rather be maintained out of tree.
The cross prefix was not likely the actual compiler that needed to be used, but
rather the standard `arm-linux-gnueabihf-gcc` compiler can just be used with
`-march=armv7`.
