Fixes rustdoc in stage 0, stage 1
When a request for rustdoc is passed for stage 0, x.py build --stage 0
src/tools/rustdoc or ensure(tool::Rustdoc { .. }) with top_stage = 0, we
return the rustdoc for that compiler (i.e., the beta rustdoc).
This fixes stage 0 of https://github.com/rust-lang/rust/issues/52186 as well as being part of general workflow improvements (making stage 0 testing for std work) for rustbuild.
The stage 1 fix (second commit) completely resolves the problem, so this fixes https://github.com/rust-lang/rust/issues/52186.
The RUSTDOC_LIBDIR should be rustc_libdir, not sysroot_libdir; rustdoc
is like the compiler and should link against rustc's libdir.
Some people currently (i.e., in general, may not be on master) have doc
tests working, but no attempt to determine why has been attempted.
Using CC, CFLAGS, CXX, CXXFLAGS, AR and RANLIB breaks cross compilation
because host is built first and has correct values. The same
values are incorrect for the target however.
This commit works around the newly-introduced LLVM shared library.
This is needed such that llvm-config run from
librustc_llvm's build script can correctly locate it's own LLVM, not the
one in stage0/lib. The LLVM build system uses the DT_RUNPATH/RUNPATH
header within the llvm-config binary, which we want to use, but because
Cargo always adds the host compiler's "libdir" (stage0/lib in our
case) to the dynamic linker's search path, we weren't properly finding
the freshly-built LLVM in llvm/lib. By restoring the environment
variable setting the search path to what bootstrap sees, the problem is
resolved and librustc_llvm correctly links and finds the appropriate
LLVM.
Several run-make-fulldeps tests are also updated with similar handling.
Use `clear_if_dirty` on std for backend changes, just as we do for
changes to rustc itself, so new codegen is correctly applied to all
later compiler stages.
Fixes#48298.
The (currently) single unit test of the compiletest tool was never
executed on CI. At least I couldn't find any references of it in the
logs. This adds a test suite for compiletest so that our tester is
tested, too.
The compiletest tests can then also be executed with:
./x.py test src/tools/compiletest
Add index page argument
@Mark-Simulacrum: I might need some help from you: in bootstrap, I want to add an argument (a new flag added into `rustdoc`) in order to generate the current index directly when `rustdoc` is documenting the `std` lib. However, my change in `bootstrap` didn't do it and I assume it must be moved inside the `Std` struct. But there, I don't see how to pass it to `rustdoc` through `cargo`. Did I miss anything?
r? @QuietMisdreavus
* Make it influence the behavior of the compiled rustc, rather than
just the rustc build system. That is, if verify_llvm_ir=true,
even manual invocations of the built rustc will verify LLVM IR.
* Enable verification of LLVM IR in CI, for non-deploy and
deploy-alt builds. This is similar to how LLVM assertions are
handled.
Clean up dependency tracking in Rustbuild [2/2]
Make `clear_if_dirty` calls in `Builder::cargo` with stamp dependencies for the given Mode.
Continuation of #50904
Ref issue #50509
r? @Mark-Simulacrum
This commit updates the debuginfo that is encoded in all of our released
artifacts by default. Currently it has paths like `/checkout/src/...` but these
are a little inconsistent and have changed over time. This commit instead
attempts to actually define the file paths in our debuginfo to be consistent
between releases.
All debuginfo paths are now intended to be `/rustc/$sha` where `$sha` is the git
sha of the released compiler. Sub-paths are all paths into the git repo at that
`$sha`.
Options:
-h, --help Display this message
--cfg SPEC Configure the compilation environment
-L [KIND=]PATH Add a directory to the library search path. The
optional KIND can be one of dependency, crate, native,
framework or all (the default).
-l [KIND=]NAME Link the generated crate(s) to the specified native
library NAME. The optional KIND can be one of static,
dylib, or framework. If omitted, dylib is assumed.
--crate-type [bin|lib|rlib|dylib|cdylib|staticlib|proc-macro]
Comma separated list of types of crates for the
compiler to emit
--crate-name NAME
Specify the name of the crate being built
--emit [asm|llvm-bc|llvm-ir|obj|metadata|link|dep-info|mir]
Comma separated list of types of output for the
compiler to emit
--print [crate-name|file-names|sysroot|cfg|target-list|target-cpus|target-features|relocation-models|code-models|tls-models|target-spec-json|native-static-libs]
Comma separated list of compiler information to print
on stdout
-g Equivalent to -C debuginfo=2
-O Equivalent to -C opt-level=2
-o FILENAME Write output to <filename>
--out-dir DIR Write output to compiler-chosen filename in <dir>
--explain OPT Provide a detailed explanation of an error message
--test Build a test harness
--target TARGET Target triple for which the code is compiled
-W, --warn OPT Set lint warnings
-A, --allow OPT Set lint allowed
-D, --deny OPT Set lint denied
-F, --forbid OPT Set lint forbidden
--cap-lints LEVEL
Set the most restrictive lint level. More restrictive
lints are capped at this level
-C, --codegen OPT[=VALUE]
Set a codegen option
-V, --version Print version info and exit
-v, --verbose Use verbose output
Additional help:
-C help Print codegen options
-W help Print 'lint' options and default settings
--help -v Print the full set of options rustc accepts command.
This optionally adds lldb (and clang, which it needs) to the build.
Because rust uses LLVM 7, and because clang 7 is not yet released, a
recent git master version of clang is used.
The lldb that is used includes the Rust plugin.
lldb is only built when asked for, or when doing a nightly build on
macOS. Only macOS is done for now due to difficulties with the Python
dependency.
If we detect a local rebuild (e.g. bootstrap compiler is the same version as target compiler), we set stage to 1.
When trying to build e.g. UnstableBook, we use Mode::ToolBootstrap and stage is 1.
Just allow Mode::ToolBootstrap and stagge != 0 if we are in a local_rebuild
Signed-off-by: Marc-Antoine Perennou <Marc-Antoine@Perennou.com>
Allow clippy to be installed with make install
After #51122 clippy is available as a component but doesn't install when building from source.
This PR allows to install clippy with extended tools.
Previously we'd only do so for stage 0 but with keep-stage
improvements it seems likely that we'll see more developers working in
the stage 1, so we should allow enabling incremental for them.
Ideally, the check we probably want is to only enable incremental for
the last compiler build scheduled, but there's no good way to do so
today. Just enabling incremental in all stages should be sufficient;
we may be doing extra work that's needles -- compiling incrementally
something that will never be recompiled in-place -- but that should be
sufficiently unlikely (i.e., users either don't care or won't be
compiling the compiler twice).
