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
Add rustc SHA to released DWARF debuginfo
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`.
docs: Use dollar sign for all bash prompts
Making it consistent across the board, as most of them already use `$`.
Also split one continues bash run into two, to make it easier see
different runs: one with warning and another with error.
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`.
Making it consistent across the board, as most of them already use `$`.
Also split one continues bash run into two, to make it easier see
different runs: one with warning and another with error.
Update `petgraph` dependency to 0.4.13 to fix build with nightly
I wanted to build Rust from source using a local nightly compiler, but I was unable to get `bootstrap` to compile due to a naming conflict with the `find_map` function.
This PR updates the `petgraph` dependency of `bootstrap` to 0.4.13, fixing the issue.
Have rust-lldb look for the rust-enabled lldb
We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup. See the discussion in
https://github.com/rust-lang-nursery/rustup.rs/pull/1492 for
background on this decision. There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed. This patch changes
rust-lldb to look in the sysroot and use the lldb found there, if any.
See issue #48168
We're shipping a rust-enabled lldb, but the "lldb" executable is not
installed into the "bin" directory by rustup. See the discussion in
https://github.com/rust-lang-nursery/rustup.rs/pull/1492 for
background on this decision. There, we agreed to have rust-lldb
prefer the rust-enabled lldb if it is installed.
This patch changes dist.rs to put lldb into rustlib, following what
was done for the other LLVM tools in #53955, and then fixes rust-lldb
to prefer that lldb, if it exists.
See issue #48168
propagate build.python into cmake
If a suitable value of Python is not on `PATH`, one can still invoke x.py
manually, which propagates `BOOTSTRAP_PYTHON` into the bootstrap
environment. But building LLVM will abort with error messages about not
being able to find Python, and instructions to set `PYTHON_EXECUTABLE`,
because nothing is done with `BOOTSTRAP_PYTHON` when invoking cmake.
Setting `build.python` in config.toml had no effect in this scenario,
either
To fix this, let's provide `PYTHON_EXECUTABLE` when invoking cmake; for
the "normal" case of Python in `PATH`, this doesn't alter any behavior.
For more unusual cases, however, this ensures cmake finds Python
properly. (This change also ensures there are no differences between
what bootstrap is using, and what cmake uses, which may be useful for
consistency's sake.)
This commit tweaks the layout of a few components that we distribute to
hopefully fix across all platforms the recent issues with LLD being unable to
find the LLVM shared object. In #53245 we switched to building LLVM as a dynamic
library, which means that LLVM tools by default link to LLVM dynamically rather
than statically. This in turn means that the tools, at runtime, need to find the
LLVM shared library.
LLVM's shared library is currently distributed as part of the rustc component.
This library is located, however, at `$sysroot/lib`. The LLVM tools we ship are
in two locations:
* LLD is shipped at `$sysroot/lib/rustlib/$host/bin/rust-lld`
* Other LLVM tools are shipped at `$sysroot/bin`
Each LLVM tool has an embedded rpath directive indicating where it will search
for dynamic libraries. This currently points to `../lib` and is presumably
inserted by LLVM's build system. Unfortunately, though, this directive is only
correct for the LLVM tools at `$sysroot/bin`, not LLD!
This commit is targeted at fixing this situation by making two changes:
* LLVM tools other than LLD are moved in the distribution to
`$sysroot/lib/rustlib/$host/bin`. This moves them next to LLD and should
position them for...
* The LLVM shared object is moved to `$sysroot/lib/rustlib/$host/lib`
Together this means that all tools should natively be able to find the shared
object and the shared object should be installed all the time for the various
tools. Overall this should...
Closes#53813
If a suitable value of Python is not on PATH, one can still invoke x.py
manually, which propagates BOOTSTRAP_PYTHON into the bootstrap
environment. But building LLVM will abort with error messages about not
being able to find Python, and instructions to set PYTHON_EXECUTABLE,
because nothing is done with BOOTSTRAP_PYTHON when invoking cmake.
Setting build.python in config.toml had no effect in this scenario,
either
To fix this, let's provide PYTHON_EXECUTABLE when invoking cmake; for
the "normal" case of Python in PATH, this doesn't alter any behavior.
For more unusual cases, however, this ensures cmake finds Python
properly. (This change also ensures there are no differences between
what bootstrap is using, and what cmake uses, which may be useful for
consistency's sake.)
set cfg(rustdoc) when rustdoc is running on a crate
When using `#[doc(cfg)]` to document platform-specific items, it's a little cumbersome to get all the platforms' items to appear all at once. For example, the standard library adds `--cfg dox` to rustdoc's command line whenever it builds docs, and the documentation for `#![feature(doc_cfg)]` suggests using a Cargo feature to approximate the same thing. This is a little awkward, because you always need to remember to set `--features dox` whenever you build documentation.
This PR proposes making rustdoc set `#[cfg(rustdoc)]` whenever it runs on a crate, to provide an officially-sanctioned version of this that is set automatically. This way, there's a standardized way to declare that a certain version of an item is specifically when building docs.
To try to prevent the spread of this feature from happening too quickly, this PR also restricts the use of this flag to whenever `#![feature(doc_cfg)]` is active. I'm sure there are other uses for this, but right now i'm tying it to this feature. (If it makes more sense to give this its own feature, i can easily do that.)
Update LLVM submodule
This commit updates the LLVM submodule to the current trunk of LLVM itself. This
brings a few notable improvements for the wasm target:
* Support for wasm atomic instructions is greatly improved
* Renamed memory wasm intrinsics are fully supported
* LLD has fixed a quadratic execution bug with large numbers of relocations in
wasm files.
The compiler-rt submodule has been updated in tandem as well.
This commit updates the LLVM submodule to the current trunk of LLVM itself. This
brings a few notable improvements for the wasm target:
* Support for wasm atomic instructions is greatly improved
* Renamed memory wasm intrinsics are fully supported
* LLD has fixed a quadratic execution bug with large numbers of relocations in
wasm files.
The compiler-rt submodule has been updated in tandem as well.
Rollup of 20 pull requests
Successful merges:
- #51760 (Add another PartialEq example)
- #53113 (Add example for Cow)
- #53129 (remove `let x = baz` which was obscuring the real error)
- #53389 (document effect of join on memory ordering)
- #53472 (Use FxHash{Map,Set} instead of the default Hash{Map,Set} everywhere in rustc.)
- #53476 (Add partialeq implementation for TryFromIntError type)
- #53513 (Force-inline `shallow_resolve` at its hottest call site.)
- #53655 (set applicability)
- #53702 (Fix stabilisation version for macro_vis_matcher.)
- #53727 (Do not suggest dereferencing in macro)
- #53732 (save-analysis: Differentiate foreign functions and statics.)
- #53740 (add llvm-readobj to llvm-tools-preview)
- #53743 (fix a typo: taget_env -> target_env)
- #53747 (Rustdoc fixes)
- #53753 (expand keep-stage --help text)
- #53756 (Fix typo in comment)
- #53768 (move file-extension based .gitignore down to src/)
- #53785 (Fix a comment in src/libcore/slice/mod.rs)
- #53786 (Replace usages of 'bad_style' with 'nonstandard_style'.)
- #53806 (Fix UI issues on Implementations on Foreign types)
Failed merges:
r? @ghost
add llvm-readobj to llvm-tools-preview
Similar to readelf but supports more object formats (it seems). Particularly useful to inspect in detail sections (e.g. their flags) and symbols (e.g. their types).
r? @alexcrichton
cc @dvc94ch
A recent change (#53245) started to build LLVM with ThinLTO enabled and to
ensure that compile times are kept down it builds LLVM dynamically by default to
ensure that all the various LLVM tools aren't redoing all that optimization
work. This means, however, that all LLVM tools depend on LLVM's dynamic library
by default.
While the LLVM tools and LLDB components were updated to include the shared
library we accidentally forgot about LLD, included with the main rustc
component. LLD also links dynamically to LLVM and ships a non-working binary
right now because of this!
This commit updates our distribution to ship the LLVM dynamic library with the
compiler libraries. While not technically needed for rustc itself to operate
(right now) it may be needed for LLD, and otherwise it serves as a good basis
for the other LLVM tools components to work with as well.
This should...
Closes#53813
[experimental]: Build LLVM with ThinLTO enabled (2nd attempt)
This is https://github.com/rust-lang/rust/pull/51207 revived. This time, I'd like to run actual performance tests to see if it improves compile times.
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.
Add crate build test for `thumb*` targets. [IRR-2018-embedded]
## Summary
This PR adds `run-make` test that compiles `cortex-m` crate for all supported `thumb*-none-*` targets using `cargo` and stage2 `rustc`.
- Supported `thumb*-none-*` targets:
- thumbv6m-none-eabi (Bare Cortex-M0, M0+, M1)
- thumbv7em-none-eabi (Bare Cortex-M4, M7)
- thumbv7em-none-eabihf (Bare Cortex-M4F, M7F, FPU, hardfloat)
- thumbv7m-none-eabi (Bare Cortex-M3)
## How to run & Example output
I tested locally and all targets succeeded like below:
```
./x.py clean
./x.py test --target thumbv6m-none-eabi,thumbv7em-none-eabi,thumbv7em-none-eabihf,thumbv7m-none-eabi src/test/run-make
```
```
Check compiletest suite=run-make mode=run-make (x86_64-unknown-linux-gnu -> thumbv6m-none-eabi)
running 5 tests
.....
test result: ok. 5 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out
```
## How to re-run
Remove `stamp` file for the test run.
```
rm build/x86_64-unknown-linux-gnu/test/run-make/thumb-none-cortex-m/stamp
```
Then run `test`
```
./x.py test --target thumbv6m-none-eabi,thumbv7em-none-eabi,thumbv7em-none-eabihf,thumbv7m-none-eabi src/test/run-make
(snip)
running 5 tests
iiii.
test result: ok. 1 passed; 0 failed; 4 ignored; 0 measured; 0 filtered out
```
## Artifacts
You can examine the artifacts under the directory below:
```
sekineh@sekineh-VirtualBox:~/rustme10$ ls -l build/x86_64-unknown-linux-gnu/test/run-make/thumb-none-cortex-m/thumb-none-cortex-m/
total 4
drwxrwxr-x 7 sekineh sekineh 4096 8月 14 22:40 cortex-m
```
where `build/x86_64-unknown-linux-gnu/test/run-make/thumb-none-cortex-m/thumb-none-cortex-m/` is came from TMPDIR variable.
## Other notes
For `test.rs` modification, I used the same logic as:
- https://github.com/rust-lang/rust/blame/d8b3c830fbcdd14d085209a8dcc3399151f3286a/src/bootstrap/dist.rs#L652-L657
```
if builder.no_std(target) == Some(true) {
// the `test` doesn't compile for no-std targets
builder.ensure(compile::Std { compiler, target });
} else {
builder.ensure(compile::Test { compiler, target });
}
```
It is a useful snippet when adding `no_std` support to `src/bootstrap` code.
CC @kennytm @jamesmunns @nerdyvaishali
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.
