| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Remove unsupported options in configure.py
I've seen people using `optimize = false` and `full-bootstrap = true` in the past, without knowing
that they're not recommended. Remove `optimize` and a few other options that are always a bad idea,
and document that full-bootstrap is only for testing reproducible builds.
|
|
Fix `x build library/std compiler/rustc`
Previously, this was broken because of improper caching:
1. `StepDescription::maybe_run` builds `Compile::Std`, which only built `std` and not `proc_macro`
1. `Std` calls `builder.ensure(StdLink)`
1. `Rustc` calls `ensure(Std)`, which builds all crates, including `proc_macro`
1. `Rustc` calls `ensure(StdLink)`. `ensure` would see that it had already been run and do nothing. <-- bug is here
1. Cargo gives an error that `proc_macro` doesn't exist.
This fixes the caching by adding `crates` to `StdLink`, so it will get rerun if the crates that are built change.
Fixes https://github.com/rust-lang/rust/issues/99129.
|
|
Before:
```
thread 'main' panicked at 'Unable to build RLS', dist.rs:42:9
```
After:
```
thread 'main' panicked at 'Unable to build submodule tool RLS (use `missing-tools = true` to ignore this failure)
note: not all tools are available on all nightlies
help: see https://forge.rust-lang.org/infra/toolstate.html for more information', dist.rs:43:9
```
|
|
Allow using `download-ci-llvm = true` outside the git checkout
`@bjorn3` noticed that this is already allowed today when download-llvm is disabled, but breaks with it enabled:
```
$ ./rust2/x.py build
fatal: not a git repository (or any of the parent directories): .git
thread 'main' panicked at 'command did not execute successfully: "git" "rev-list" "--author=bors@rust-lang.org" "-n1" "--first-parent" "HEAD" "--" "/home/jnelson/rust-lang/rust2/src/llvm-project" "/home/jnelson/rust-lang/rust2/src/bootstrap/download-ci-llvm-stamp" "/home/jnelson/rust-lang/rust2/src/version"
expected success, got: exit status: 128', src/bootstrap/native.rs:134:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Support it too for consistency. It's unclear to me when anyone would need to use this, but `@bjorn3`
feels we should support it, and it's not much additional effort to get it working.
|
|
Previously, this was broken because of improper caching:
1. `StepDescription::maybe_run` builds `Compile::Std`, which only built `std` and not `proc_macro`
1. `Std` calls `builder.ensure(StdLink)`
1. `Rustc` calls `ensure(Std)`, which builds all crates, including `proc_macro`
1. `Rustc` calls `ensure(StdLink)`. `ensure` would see that it had already been run and do nothing. <-- bug is here
1. Cargo gives an error that `proc_macro` doesn't exist.
This fixes the caching by adding `crates` to `StdLink`, so it will get rerun if the crates that are
built change. This also does the same for `RustcLink`; it doesn't matter in practice currently
because nothing uses it except `impl Step for Rustc`, but it will avoid bugs if we start using it in
the future (e.g. to build individual crates for rustfmt).
|
|
LLVM tools should also be patched, since they are used in some tests,
specially,
- src/test/run-make-fulldeps/cross-lang-lto (llvm-ar)
- src/test/run-make-fulldeps/cross-lang-lto-upstream-rlibs (llvm-ar)
- src/test/run-make-fulldeps/issue-64153 (llvm-objdump)
To be more future proof, we should patch all binaries in `bin`.
|
|
@bjorn3 noticed that this is already allowed today when download-llvm is disabled, but breaks with it enabled:
```
$ ./rust2/x.py build
fatal: not a git repository (or any of the parent directories): .git
thread 'main' panicked at 'command did not execute successfully: "git" "rev-list" "--author=bors@rust-lang.org" "-n1" "--first-parent" "HEAD" "--" "/home/jnelson/rust-lang/rust2/src/llvm-project" "/home/jnelson/rust-lang/rust2/src/bootstrap/download-ci-llvm-stamp" "/home/jnelson/rust-lang/rust2/src/version"
expected success, got: exit status: 128', src/bootstrap/native.rs:134:20
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```
Support it too for consistency. It's unclear to me when anyone would need to use this, but @bjorn3
feels we should support it, and it's not much additional effort to get it working.
This also updates a bunch of other git commands that were similarly depending on the current directory.
|
|
I've seen people using `optimize = false` and `full-bootstrap = true` in the past, without knowing
that they're not recommended. Remove `optimize` and a few other options that are always a bad idea,
and document that full-bootstrap is only for testing reproducible builds.
|
|
This includes the following pull requests:
* https://github.com/rust-lang/rust-installer/pull/114
* https://github.com/rust-lang/rust-installer/pull/113
|
|
Fix several issues during cross compiling
- When cross compiling LLVM on an arm64 macOS machine to x86_64, CMake will produce universal binaries by default, causing link errors. Explicitly set `CMAKE_OSX_ARCHITECTURES` to the one single target architecture so that the executables and libraries will be single architecture.
- When cross compiling rustc with `llvm.clang = true`, `CLANG_TABLEGEN` has to be set to the host `clang-tblgen` executable to build clang.
|
|
Fix caching bug in `download-rustc = true`
When moving this to rustbuild, I introduced a bug: if you had the file already downloaded, but
deleted the sysroot for whatever reason, rustbuil would fail to unpack the cached tarball.
This only affects people if they have a cached tarball, which is probably why we haven't seen an issue yet -
wiping `build/cache` would work around the issue, or just not deleting `build/$TARGET/stage2`.
Fixes the following error:
```
thread 'main' panicked at 'fs::read_dir(&lib_dir) failed with No such file or directory (os error 2) ("/home/jnelson/rust-lang/rust2/build/x86_64-unknown-linux-gnu/ci-rustc/lib")', config.rs:1563:20
```
r? ``@Mark-Simulacrum``
|
|
replace process exit with more detailed exit in src/bootstrap/*.rs
Fixes [#98830](https://github.com/rust-lang/rust/issues/98830)
I implemeted "detail_exit.rs" in lib.rs, and replace all of std::process::exit.
So, error code should panic in test code.
```
// lib.rs
pub fn detail_exit(code: i32) -> ! {
// Successful exit
if code == 0 {
std::process::exit(0);
}
if cfg!(test) {
panic!("status code: {}", code);
} else {
std::panic::resume_unwind(Box::new(code));
}
}
```
<details>
<summary>% rg "exit\(" src/bootstrap/*.rs</summary>
```
builder.rs
351: crate::detail_exit(1);
1000: crate::detail_exit(1);
1429: crate::detail_exit(1);
compile.rs
1331: crate::detail_exit(1);
config.rs
818: crate::detail_exit(2);
1488: crate::detail_exit(1);
flags.rs
263: crate::detail_exit(exit_code);
349: crate::detail_exit(exit_code);
381: crate::detail_exit(1);
602: crate::detail_exit(1);
616: crate::detail_exit(1);
807: crate::detail_exit(1);
format.rs
35: crate::detail_exit(1);
117: crate::detail_exit(1);
lib.rs
714: detail_exit(1);
1620: detail_exit(1);
1651:pub fn detail_exit(code: i32) -> ! {
1654: std::process::exit(0);
sanity.rs
107: crate::detail_exit(1);
setup.rs
97: crate::detail_exit(1);
290: crate::detail_exit(1);
test.rs
676: crate::detail_exit(1);
1024: crate::detail_exit(1);
1254: crate::detail_exit(1);
tool.rs
207: crate::detail_exit(1);
toolstate.rs
96: crate::detail_exit(3);
111: crate::detail_exit(1);
182: crate::detail_exit(1);
228: crate::detail_exit(1);
util.rs
339: crate::detail_exit(1);
378: crate::detail_exit(1);
468: crate::detail_exit(1);
```
</details>
|
|
implement detail_exit but I'm not sure it is right.
not create new file and write detail exit in lib.rs
replace std::process::exit to detail_exit
that is not related to code runnning.
remove pub
|
|
|
|
Proper macOS libLLVM symlink when cross compiling
Follow up of #98418
When cross compiling on macOS with `llvm.link-shared` enabled, the symlink creation will fail after compiling LLVM for the target architecture, because it will attempt to create the symlink in the host LLVM directory, which was already created when being built.
This commit changes the symlink path to the actual LLVM output.
r? `@jyn514`
|
|
bootstrap: Allow building individual crates
This aims to be as unintrusive as possible, but did still require adding a new `tail_args` field to all `Rustc` and `Std` steps.
New library and compiler crates are added to the sysroot as they are built, since it's useful to have e.g. just alloc and not std.
Fixes https://github.com/rust-lang/rust/issues/44293.
|
|
bootstrap.py: Always use `.exe` for Windows
This ensures that it will run the Windows executable if other files in the directory (such as Linux executables) have the same file name minus the extension. I've been tripped up by this a few times where both `bootstrap` and `bootstrap.exe` end up in the same directory.
This PR avoids ever having to see the following message:
`OSError: [WinError 193] %1 is not a valid Win32 application`
|
|
Co-authored-by: Marco Colombo <mar.colombo13@gmail.com>
|
|
This ensure that it will run the Windows executable if other files in the directory (such as Linux executables) have the same file name minus the extension.
|
|
Only obey optimize-tests flag on UI tests that are run-pass
stage1 UI tests walltime on my machine:
```
optimize-tests = false, master
25.98s
optimize-tests = true, master
34.69s
optimize-tests = true, patched
28.79s
```
Effects:
- faster UI tests
- llvm asserts get exercised less on build-pass tests
- the difference between opt and nopt builds shrinks a bit
- aux libs don't get optimized since they don't have a pass mode and almost never have explicit compile flags
|
|
When cross compiling on macOS with `llvm.link-shared` enabled,
the symlink creation will fail after compiling LLVM for the target
architecture, because it will attempt to create the symlink in the
host LLVM directory, which was already created when being built.
This commit changes the symlink path to the actual LLVM output.
|
|
When cross compiling rustc with `llvm.clang = true`, CLANG_TABLEGEN
has to be set to the host clang-tblgen executable to build clang.
|
|
When cross compiling LLVM on an arm64 machine to x86_64, CMake will
produce universal binaries by default, causing link errors. Explicitly
set CMAKE_OSX_ARCHITECTURES to the one single target architecture.
|
|
Revert #95993 fix
This reverts the temporary fix implemented by https://github.com/rust-lang/rust/pull/95993 since a permanent fix has been implemented by https://github.com/rust-lang/cargo/pull/10594
Fixes https://github.com/rust-lang/rust/issues/98728
|
|
|
|
Signed-off-by: InfRandomness <infrandomness@gmail.com>
|
|
This adds miri to https://doc.rust-lang.org/nightly/nightly-rustc/
Signed-off-by: InfRandomness <infrandomness@gmail.com>
|
|
Move locking from bootstrap.py to rust bootstrap, using fd-lock
Helps with https://github.com/rust-lang/rust/issues/94829.
|
|
|
|
- Add `Interned<Vec<String>>` and use it for tail args
- Refactor `cache.rs` not to need a separate impl for each internable type
|
|
This makes it much simpler to add new interned types, rather than having
to add 4+ impl blocks for each type.
|
|
|
|
Fix `x dist rust-dev` on a fresh checkout
Previously, it required you to manually run `x build` first, because it
assumed the LLVM binaries were already present.
|
|
```
optimize-tests = false, master
25.98s
optimize-tests = true, master
34.69s
optimize-tests = true, patched
28.79s
```
Effects:
- faster UI tests
- llvm asserts get exercised less on build-pass tests
- the difference between opt and nopt builds shrinks a bit
- aux libs don't get optimized since they don't have a pass mode and almost never have explicit compile flags
|
|
bootstrap: illumos platform flags for split-debuginfo
Bootstrap currently provides `-Zunstable-options` for platforms
when using split debuginfo - this commit adds it for the illumos
target too.
|
|
When moving this to rustbuild, I introduced a bug: if you had the file already downloaded, but
deleted the sysroot for whatever reason, rustbuil would fail to unpack the cached tarball.
This only affects people if they have a cached tarball, which is probably why we haven't seen an issue yet -
wiping `build/cache` would work around the issue, or just not deleting `build/$TARGET/stage2`.
|
|
Allow macOS to build LLVM as shared library
Inspired by how [homebrew](https://github.com/Homebrew/homebrew-core/blob/HEAD/Formula/llvm.rb) builds and distributes llvm, here we manually create a symlink with a versioned dylib path to make `llvm-config` work properly. Note, the resulting `rustc` executable and `librustc_driver-<hash>.dylib` still links to the un-versioned `libLLVM.dylib` as expected when distributed in the final output. I have confirmed this by checking `otool -L` on both binaries.
After the change, enabling `llvm.link-shared` and `llvm.thin-lto` will be possible on macOS.
|
|
Bootstrap currently provides `-Zunstable-options` for platforms
when using split debuginfo - this commit adds it for the illumos
target too.
|
|
Add a `--build-dir` flag to rustbuild
This adds an optional `--build-dir <path>` flag to rustbuild (to both the python and rust code in src/bootstrap). If provided, it overrides build directory from the config file (if any was provided).
My reason for wanting this is that I often will make a change, save, and then go run `x.py check` or `x.py test` (or something). Because I've saved, vscode will start doing its thing in the background, but this will take the file lock, preventing `x.py` from running until vscode finishes whatever it's doing (since the manually invoked x.py won't be able to acquire said file lock). This is annoying, because I'd rather the command I explicitly invoke *not* wait for r-a to complete, as r-a's check is conceptually a background task (and one which can take quite some time to complete).
Anyway, while there are likely other ways this could be handled, if you have the disk space an easy way is to just have vscode be configured to use a different build directory, and then they never have to block each-other.
This can currently be arranged without this patch, by maintaining two `config.toml`s, one of which has a different build dir, and just exists to be passed into the overridden check command in vscode.
Unfortunately, this has the downside of requiring I maintain two `config.toml`s and keep them (at least somewhat) in sync, aside from the build dir. I dislike for several reasons, not the least of which because I know myself well enough to know that these will inevitably get out of sync and confuse me in the future (perhaps this case would be different since I've thought about it enough to write this patch? Who knows, I'd rather not find out).
Either way, it would be much easier for me to have a way for *only* the build directory to differ, which this patch provides by way of a new flag. I suggested this to `@jyn514` who indicated it sounded reasonable so long as it didn't add too much complexity, which I think I've achieved, but he can be the judge.
Anyway, with this patch I can just use something like `["python3", "x.py", "check", "--build-dir", "build-vscode", "--json-output"]` as the overridden check command to rust-analyzer, and do not need to futz with any additional `config.toml`s. Which is very nice!
I've tested this manually, and can confirm that it works. I'm not sure if it needs automated tests, or where I should add them if so.
r? `@jyn514` (who has had to put up with my complaints about this... many times. <3)
|
|
Let rust-analyzer ship on stable, non-preview
The consensus on rust-lang/rust-analyzer#12432 seems to be that we are ready for `rust-analyzer` to ship as a rustup component on the beta and stable channels. This won't always be the preferred distribution method, e.g. the VS Code extension will probably still independently update to its weekly releases, but it's still useful to have a component that follows the release train with the rest of the Rust toolchain. So this removes the nightly-only gating on the bundled component, and removes the "-preview" suffix as well by the usual renaming mechanism.
cc ``@rust-lang/wg-rls-2`` ``@rust-lang/release``
|
|
Previously, it required you to manually run `x build` first, because it
assumed the LLVM binaries were already present.
|
|
|
|
This reverts the temporary fix implemented by https://github.com/rust-lang/rust/pull/95993 since a permanent fix has been implemented by https://github.com/rust-lang/cargo/pull/10594
|
|
|
|
Ensure that `static_crt` is set in the bootstrapper whenever using `cc-rs` to get a compiler command line.
When attempting to build rustc with LLVM on Windows, I noticed that the CRT flag provided to the C and C++ Compilers was inconsistent:
```
"-DCMAKE_C_FLAGS=-nologo -MT -Brepro" "-DCMAKE_CXX_FLAGS=-nologo -MD -Brepro"
```
Since the bootstrapper also sets the various `LLVM_USE_CRT` variables, this resulted in cl.exe reporting a bunch of warnings:
```
cl : Command line warning D9025 : overriding '/MD' with '/MT'
```
The root cause for this is that `cc_detect::find` was creating a `cc::Build` twice, but didn't set `static_crt` the second time.
It's possible that this what is also causing #81381
|
|
|
|
get a compiler command line.
When attempting to build rustc with LLVM on Windows, I noticed that the CRT flag provided to the C and C++ Compilers was inconsistent:
```
"-DCMAKE_C_FLAGS=-nologo -MT -Brepro" "-DCMAKE_CXX_FLAGS=-nologo -MD -Brepro"
```
Since the bootstrapper also sets the various `LLVM_USE_CRT` variables, this resulted in cl.exe reporting a bunch of warnings:
```
cl : Command line warning D9025 : overriding '/MD' with '/MT'
```
The root cause for this is that `cc_detect::find` was creating a `cc::Build` twice, but didn't set `static_crt` the second time.
It's possible that this what is also causing #81381
|
|
|
