This commit updates the `dist` target for MSVC to not build the mingw components
and to also ensure that the `llvm-ar.exe` binary is ferried along into the right
location for installs.
Windows needs explicit exports of functions from DLLs but LLVM does not mention
any of its symbols as being export-able from a DLL. The compiler, however,
relies on being able to use LLVM symbols across DLL boundaries so we need to
force many of LLVM's symbols to be exported from `rustc_llvm.dll`. This commit
adds support for generation of a `rustc_llvm.def` file which is passed along to
the linker when generating `rustc_llvm.dll` which should keep all these symbols
exportable and usable.
The compiler will require that `llvm-ar.exe` be available for MSVC-targeting
builds (more comments on this soon), so this commit adds support for targets to
depend on LLVM tools. The `core` library for MSVC depends on `llvm-ar.exe` which
will be copied into place for the target before the compiler starts to run.
Note that these targets all depend on `llvm-config.exe` to ensure that they're
built before they're attempted to be copied.
This commit updates the rustllvm.mk file with the necessary flags and such to
build rustllvm.lib with cl.exe instead of gcc. Some comments can be found in the
commit itself.
It looks like compiler-rt has a cmake build sytem inside its source, but I have
been unable to figure out how to use it and actually build the right library.
For now this commit hard-wires MSVC-targeting builds of libcompiler-rt to
continue using `make` as the primary bulid system, but some frobbing of the
flags are necessary to ensure that the right compiler is used.
Currently the MSVC compilers don't have any cross prefixes and we're only able
to make an MSVC compiler with a cross compile, so just avoid this logic on msvc
for now.
We have a number of support C/C++ files in Rust that we link into the standard
library and other various locations, and these all need to be built with cl.exe
instead of gcc.exe when targeting MSVC. This commit adds helper macros for this
functionality to use different sets of programs/flags/invocations on MSVC than
on GNU-like platforms.
This commit modifies the makefiles to enable building LLVM with cmake and Visual
Studio to generate an LLVM that targets MSVC. Rust's configure script requires
cmake to be installed when targeting MSVC and will configure LLVM with cmake
instead of the normal `./configure` script LLVM provides. The build will then
run cmake to execute the build instead of the normal `make`.
Currently `make clean-llvm` isn't supported on MSVC as I can't figure out how to
run a "clean" target for the Visual Studio files.
This commit starts to add MSVC support to the ./configure script to enable the
build system to detect and build an MSVC target with the cl.exe compiler and
toolchain. The primary change here is a large sanity check when an MSVC target
is requested (and currently only `x86_64-pc-windows-msvc` is recognized).
When building an MSVC target, the configure script either requires the
`--msvc-root` argument or for `cl.exe` to be in `PATH`. It also requires that if
in the path `cl.exe` is the 64-bit version of the compiler.
Once detected the configure script will run the `vcvarsall.bat` script provided
by Visual Studio to learn about the `INCLUDE` and `LIB` variables needed by the
`cl.exe` compiler to run (the default include/lib paths for the
compiler/linker). These variables are then reexported when running `make` to
ensure that our own compiles are running the same toolchain.
The purpose of this detection and environment variable scraping is to avoid
requiring the build itself to be run inside of a `cmd.exe` shell but rather
allow it to run in the currently expected MinGW/MSYS shell.
We use a script called `mklldeps.py` to run `llvm-config` to generate a list
of LLVM libraries and native dependencies needed by LLVM, but all cross-compiled
LLVM builds were using the *host triple's* `llvm-config` instead of the
*target's* `llvm-config`. This commit alters this to require the right
`llvmdeps.rs` to be generated which will run the correct `llvm-config`.
Previously libmorestack.a and libcompiler-rt.a were installed, but link.exe
looks for morestack.lib and compiler-rt.lib by default, so we need to install
these with the correct name
The code takes a prefix of the MD5 hash of the version string.
Since the hash command differs across GNU and BSD platforms, we scan for
the right one in the configure script.
Closes#25007
The code takes a prefix of the MD5 hash of the version string.
Since the hash command differs across GNU and BSD platforms, we scan for
the right one in the configure script.
Closes#25007
Then, decouple the question of whether the compiler/stdlib carry
debuginfo (which is controlled via `--enable-debuginfo` and implied by
`--enable-debug`) from the question of whether the tests carry
debuginfo (which now no longer is implied by `--enable-debug` nor
`--enable-debuginfo`, and is off by default).
These commits build on [some great work on reddit](http://www.reddit.com/r/rust/comments/33boew/weekend_experiment_link_rust_programs_against/) for adding MUSL support to the compiler. This goal of this PR is to enable a `--target x86_64-unknown-linux-musl` argument to the compiler to work A-OK. The outcome here is that there are 0 compile-time dependencies for a MUSL-targeting build *except for a linker*. Currently this also assumes that MUSL is being used for statically linked binaries so there is no support for dynamically linked binaries with MUSL.
MUSL support largely just entailed munging around with the linker and where libs are located, and the major highlights are:
* The entirety of `libc.a` is included in `liblibc.rlib` (statically included as an archive).
* The entirety of `libunwind.a` is included in `libstd.rlib` (like with liblibc).
* The target specification for MUSL passes a number of ... flavorful options! Each option is documented in the relevant commit.
* The entire test suite currently passes with MUSL as a target, except for:
* Dynamic linking tests are all ignored as it's not supported with MUSL
* Stack overflow detection is not working MUSL yet (I'm not sure why)
* There is a language change included in this PR to add a `target_env` `#[cfg]` directive. This is used to conditionally build code for only MUSL (or for linux distros not MUSL). I highly suspect that this will also be used by Windows to target MSVC instead of a MinGW-based toolchain.
To build a compiler targeting MUSL you need to follow these steps:
1. Clone the current MUSL repo from `git://git.musl-libc.org/musl`. Build this as usual and install it.
2. Clone and build LLVM's [libcxxabi](http://libcxxabi.llvm.org/) library. Only the `libunwind.a` artifact is needed. I have tried using upstream libunwind's source repo but I have not gotten unwinding to work with it unfortunately. Move `libunwind.a` adjacent to MUSL's `libc.a`
3. Configure a Rust checkout with `--target=x86_64-unknown-linux-musl --musl-root=$MUSL_ROOT` where `MUSL_ROOT` is where you installed MUSL in step 1.
I hope to improve building a copy of libunwind as it's still a little sketchy and difficult to do today, but other than that everything should "just work"! This PR is not intended to include 100% comprehensive support for MUSL, as future modifications will probably be necessary.
There were a few test cases to fix:
* Dynamic libraries are not supported with MUSL right now, so all of those
related test which force or require dylibs are ignored.
* Looks like the default stack for MUSL is smaller than glibc, so a few stack
allocations in benchmarks were boxed up (shouldn't have a perf impact).
* Some small linkage tweaks here and there
* Out-of-stack detection does not currently work with MUSL
This commit adds support to the makefiles, configuration script, and build
system to understand MUSL. This is broken up into a few parts:
* Any target of the form `*-musl` requires the `--musl-root` option to
`./configure` which will indicate the root of the MUSL installation. It is
also expected that there is a libunwind build inside of that installation
built against that MUSL.
* Objects from MUSL are copied into the build tree for Rust to be statically
linked into the appropriate Rust library.
* Objects for binary startup and shutdown are included in each Rust installation
by default for MUSL. This requires MUSL to only be installed on the machine
compiling rust. Only a linker will be necessary for compiling against MUSL on
a target machine.
Eventually a MUSL and/or libunwind build may be integrated by default into the
build but for now they are just always assumed to exist externally.
In most places in mk/tests.mk, it's positioned after rpass-full and
before cfail-full (because rfail comes before cfail). The order of tests
seems a little inconsistent, but reordering everywhere would obscure this
commit.
This required fixing the `pretty-rpass-full` tests to have the same `$$(CSREQ$(1)_T_$(2)_H_$(3))` dependencies as the `rpass-full` and `cfail-full` tests. It also required fixing the `run-make/simd-ffi` test to use unique names for its output files.
The current code attempts to define the
PRETTY_DEPS$(1)_H_$(3)_pretty-rpass-full variable, which does not work,
because $(1) and $(3) are not inside a function. Moreover, there is a test
(run-pass-fulldeps/compiler-calls.rs) that uses rustc_driver, which is not
an indirect dependency of librustc or libsyntax. Listing all the
dependencies will be hard to maintain, but there's a better way to do
this...
As with the rpass-full and cfail-full tests, add dependencies using the
$$(CSREQ$(1)_T_$(3)_H_$(3)) variable, which includes the complete set of
host and target crates, built for a particular stage and host. We use
T_$(3), not T_$(2), because we only build LLVM for host triples (not
target triples), so we can only build rustc_llvm for host triples. The
fulldeps tests that use plugins need host rustc crates, whereas fulldeps
tests that link against rustc and run should be skipped for
cross-compilation (such as Android).
Fixes#22021
Instead of rustc-1.0.0-beta-$triple.tar.gz, betas will be named
rustc-beta-$triple.tar.gz. This will give betas a stable download
URL, prevent old artifacts from accumulating in the dist server's
root directory, and not require the website to be updated every
beta.
As a tradeoff, it will be harder to download previous betas because
they will need to be located in the archives.
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
This patch
1. renames libunicode to librustc_unicode,
2. deprecates several pieces of libunicode (see below), and
3. removes references to deprecated functions from
librustc_driver and libsyntax. This may change pretty-printed
output from these modules in cases involving wide or combining
characters used in filenames, identifiers, etc.
The following functions are marked deprecated:
1. char.width() and str.width():
--> use unicode-width crate
2. str.graphemes() and str.grapheme_indices():
--> use unicode-segmentation crate
3. str.nfd_chars(), str.nfkd_chars(), str.nfc_chars(), str.nfkc_chars(),
char.compose(), char.decompose_canonical(), char.decompose_compatible(),
char.canonical_combining_class():
--> use unicode-normalization crate
This commit series starts out with more official test harness support for rustdoc tests, and then each commit afterwards adds a test (where appropriate). Each commit should also test and finish independently of all others (they're all pretty separable).
I've uploaded a [copy of the documentation](http://people.mozilla.org/~acrichton/doc/std/) generated after all these commits were applied, and a double check on issues being closed would be greatly appreciated! I'll also browse the docs a bit and make sure nothing regressed too horribly.
This commit ceases documentation-by-default of crates such as `term`,
`serialize`, and `alloc`. Crates like `term` and `rand` have duplicates on
`crates.io` and the search index entries generated in the local tree end up
only leading to confusion. Crates like the entire compiler infrastructure,
`flate`, or `rbml` don't need to be documented in such a prominent location.
This change also means that doc tests will no longer be run for crates beyond
the facade (e.g. `serialize` or `term`), but there were very few doc tests in
there to begin with.
Closes#22168
Add a new test directory called 'rustdoc' where all files inside are documented
and run against the `htmldocck` script to have assertions about the output.
Rationale for this, is that I lurked `ulimit -c unlimited` into my .profile to debug an unrelated crash, that I kept forgetting to set before hand. I then ran the test suite and discovered that I had 150 gigs of core dumps in `/cores`.
Very open to another approach, or to setting the limit to something higher than 0, but I think it would be nice if the build system tried to save you from yourself here.
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want them.
(Crates behind the facade are not documented at all)
[breaking-change]
This saves a bunch of a time and will make distributions smaller, as well as
avoiding filling the implementors page with internal garbage. Turn it back on
with `--enable-compiler-docs` if you want compiler docs during development.
Crates behind the facade are only documented on nightly/dev builds (where they
can be used).
[breaking-change]
Closes#23772Closes#21297
The RUST_TARGET_STAGE_N rule uses LLVM_LIBDIR_RUSTFLAGS_<target-triple>,
which expands to -L "$(llvm-config --libdir)" when the target-triple is
also a host-triple. Rather than expand to -L "" if llvm-config has not yet
been built, add a dependency on the target llvm-config.
When the target-triple is not a host-triple, the new LLVM_CONFIG_$(2)
dependency should expand to nothing.
r? alexcrichton
The RUST_TARGET_STAGE_N rule uses LLVM_LIBDIR_RUSTFLAGS_<target-triple>,
which expands to -L "$(llvm-config --libdir)" when the target-triple is
also a host-triple. Rather than expand to -L "" if llvm-config has not yet
been built, add a dependency on the target llvm-config.
When the target-triple is not a host-triple, the new LLVM_CONFIG_$(2)
dependency should expand to nothing.
LLVM_LIBDIR_<triple> is only defined for host triples, not target triples.
FWIW, the same is true for LLVM_STDCPP_RUSTFLAGS_<triple>, where we
explicitly define it as empty when --enable-llvm-static-stdcpp is not
specified, but it's still undefined for cross-compiled triples.
This commit is an implementation of [RFC 563][rfc] which adds a new
`cfg(debug_assertions)` directive which is specially recognized and calculated
by the compiler. The flag is turned off at any optimization level greater than 1
and may also be explicitly controlled through the `-C debug-assertions`
flag.
[rfc]: https://github.com/rust-lang/rfcs/pull/563
The `debug_assert!` and `debug_assert_eq!` macros now respect this instead of
the `ndebug` variable and `ndebug` no longer holds any meaning to the standard
library.
Code which was previously relying on `not(ndebug)` to gate expensive code should
be updated to rely on `debug_assertions` instead.
Closes#22492
[breaking-change]
This commit deprecates the majority of std::old_io::fs in favor of std::fs and
its new functionality. Some functions remain non-deprecated but are now behind a
feature gate called `old_fs`. These functions will be deprecated once
suitable replacements have been implemented.
The compiler has been migrated to new `std::fs` and `std::path` APIs where
appropriate as part of this change.
Strategy: If the end goal is to touch e.g. `stamp.std`, then we first
touch `stamp.std.start_time` before doing anything else. Then when
the receipe finishes, we touch `stamp.std` using the timestamp from
`stamp.std.start_time` as the reference time, and remove
`stamp.std.start_time`.
Fix#6518.
This pulls out the implementations of most built-in lints into a
separate crate, to reduce edit-compile-test iteration times with
librustc_lint and increase parallelism. This should enable lints to be
refactored, added and deleted much more easily as it slashes the
edit-compile cycle to get a minimal working compiler to test with (`make
rustc-stage1`) from
librustc -> librustc_typeck -> ... -> librustc_driver ->
libcore -> ... -> libstd
to
librustc_lint -> librustc_driver -> libcore -> ... libstd
which is significantly faster, mainly due to avoiding the librustc build
itself.
The intention would be to move as much as possible of the infrastructure
into the crate too, but the plumbing is deeply intertwined with librustc
itself at the moment. Also, there are lints for which diagnostics are
registered directly in the compiler code, not in their own crate
traversal, and their definitions have to remain in librustc.
This is a [breaking-change] for direct users of the compiler APIs:
callers of `rustc::session::build_session` or
`rustc::session::build_session_` need to manually call
`rustc_lint::register_builtins` on their return value.
This should make #22206 easier.
After making `rustc` fail on errors at a stop point, like `-Z parse-only`, in #22117, the files in this PR also fail during the parse stage and should be moved as well. Sorry for spliting this move up in two PRs.
- Now "make check-stage2-T-aarch64-linux-android-H-x86_64-unknown-linux-gnu" works (#21773)
- Fix & enable debuginfo tests for android (#10381)
- Fix & enable more tests for android (both for arm/aarch64)
- Enable many already-pass tests on android (both for arm/aarch64)
`cp -a` is a GNU extension. Use an alternate combinaison of POSIX options
(`-PRp`) that do nearly the same.
The difference is `-a` will preserve context, links and xattr attributes,
whereas `-p` not. But as we use it only for copy a file, there is no
difference in the current context.
This is a patch for #22291.
PLEASE_BENCH=1 adds --bench to the arguments passed to the executable to be tested. At the moment, compiletest does not accept a --bench argument, because it is not needed for any test in src/test/, even the tests in src/test/bench do not use #[bench].
I have updated the makefile to only add the --bench flag for crate tests. I do not think that changing compiletest add --bench to the run arguments of all compile tests makes sense, because it would mess up tests which check command line arguments. Also the bench option can be added as comment in a compile test as well.
Highlights:
* Adds an 'uninstall.sh' script to `/usr/local/lib/rustlib/uninstall.sh`, the path to which is printed during installation.
* Components can be deselected during install, like `install.sh --without=rust-docs`.
* Components can be listed with `install.sh --list-components`.
* Vastly reduces spew during install (but supporting a `--verbose` option).
Typicall install run looks like:
```
brian@brianX1:~/dev/multirust⟫ sudo ./install.sh
[sudo] password for brian:
install: creating uninstall script at /usr/local/lib/rustlib/uninstall.sh
install: installing component 'rustc'
install: installing component 'cargo'
install: installing component 'rust-docs'
Rust is ready to roll.
```
Needs to be merged right before corresponding PRs to cargo and rust-packaging.
Fixes https://github.com/rust-lang/rust/issues/21117
Fixes https://github.com/rust-lang/rust/issues/20283
`cp -a` is a GNU extension. Use an alternate combinaison of POSIX options
(`-PRp`) that do nearly the same.
The difference is `-a` will preserve context, links and xattr attributes,
whereas `-p` not. But as we use it only for copy a file, there is no
difference in the current context.
