| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
|
|
|
|
Update mdbook
This updates mdbook from 0.4.21 to 0.4.25. The list of changes is [here](https://github.com/rust-lang/mdBook/blob/master/CHANGELOG.md#mdbook-0425). The only user-visible changes are some changes around the theme picker, and change to the copy-to-clipboard ignoring hidden lines.
Internally there were some dependency updates and small fixes.
This also updates `clap` from 4.0.15 to 4.0.32 whose changelog is [here](https://github.com/clap-rs/clap/blob/master/CHANGELOG.md#4032---2022-12-22). This impacts tools like cargo. I don't see anything particularly noteworthy there, though there are some small user-visible changes.
Unfortunately this required adding a hack for building `rustix` with a bootstrap tool. The comment explains why. I am unable to think of some other workaround (or even a cleaner way to set the rustflag). Ideas are welcome if you can think of alternatives. I'm struggling to even think of a long-term solution, other than asking projects not to do auto-nightly feature detection.
One medium-term solution is to avoid the clap dependency for the mdbook library (which is how rustix gets pulled in). That is one of my goals for the 0.5 release of mdbook, but that probably won't happen until later this year. It would also require dropping clap from `rustbook` and using some other means to parse arguments (there's only two options, so it can probably be done manually).
|
|
|
|
This reverts commit 9dfe50440e6d48bd2fd40a4b7b3992998e55eace.
Fixes `x clippy`.
|
|
|
|
This allows getting rid of some documentation and an extra step when building a custom toolchain: https://rustc-dev-guide.rust-lang.org/building/how-to-build-and-run.html#creating-a-rustup-toolchain
and it seems likely that people will want to do this if they want rustdoc (which is also built by default).
|
|
|
|
|
|
|
|
Enable `x.py check` for miri
Now that the miri subtree is working properly, let's add it to x.py check.
cc `@rust-lang/miri`
|
|
All tools meant to be shipped with host toolchains only should be marked
as `ONLY_HOSTS = true`, but rust-analyzer was marked as `ONLY_HOSTS =
false` incorrectly. This meant that bootstrap attempted to build
rust-analyzer for cross-compilation-only targets, causing errors because
libstd is not present on some of them.
It will still be possible to cross-compile rust-analyzer by passing a
different --host flag to ./x, like you can cross-compile other tools.
|
|
|
|
|
|
The rls stub is a simple stable tool, which doesn't need compiler libs.
|
|
|
|
Allow building `rust-analyzer-proc-macro-srv` as a standalone tool
This PR allows building `rust-analyzer-proc-macro-srv` as a standalone tool via `x b proc-macro-srv-cli` (I thought that `x b rust-analyzer-proc-macro-srv` should work, but it doesn't for some reason...). Also this PR adds a copy of `rust-analyzer-proc-macro-srv` binary to `build/{triple}/{stage}/libexec/` when building `rust-analyzer-proc-macro-srv`, so that r-a can pick it up.
This is useful to make r-a (and I assume Intellij IDEA) to expand macros when using a custom, build from source toolchain.
r? ``@jyn514``
[_zulip thread_](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/How.20to.20fix.20.60UnsupportedABI.60.20for.20custom.20toolchains.3F/near/299040175)
|
|
|
|
|
|
|
|
|
|
This tool is to be ran at specific points in the release process to replace
the version place holder made by stabilizations with the version number.
|
|
|
|
features, if some of lists actually empty
|
|
This builds `src/tools/rust-analyzer/crates/proc-macro-srv-cli` and
ships it as part of Rustc's dist component. This allows rust-analyzer's
proc macro support to work on all rustc versions (stable, beta and
nightly) starting now.
|
|
- use `path` instead of `paths`
- don't mark rust-analyzer as an optional tool
- print the cargo command that's run in the proc-macro-test build script
this originally was part of a change to fix `test --stage 0 rust-analyzer`,
but I'm going to leave that for a separate PR so it's easier to review.
|
|
|
|
|
|
|
|
This includes the following pull requests:
* https://github.com/rust-lang/rust-installer/pull/114
* https://github.com/rust-lang/rust-installer/pull/113
|
|
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
|
|
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.
|
|
- Add `Interned<Vec<String>>` and use it for tail args
- Refactor `cache.rs` not to need a separate impl for each internable type
|
|
|
|
This saves a lot of time compiling.
|
|
Move download-rustc from python to rustbuild
- Remove download-rustc handling from bootstrap.py
- Allow a custom `pattern` in `builder.unpack()`
- Only download rustc once another part of bootstrap depends on it.
This is somewhat necessary since the download functions rely on having a full
`Builder`, which isn't available until after config parsing finishes.
Helps with https://github.com/rust-lang/rust/issues/94829.
|
|
r=Mark-Simulacrum
Print stderr consistently
Solves https://github.com/rust-lang/rust/issues/96712
I tried to follow what I perceived as the general consensus for error messages in boostrap i.e messages that were ..
* resulting from an Err(...) =>
* literally called as "Error: ...."
* by the end of the block scope forced to run a panic! or process::exit with a guaranteed non-zero error code.
|
|
|
|
- Remove download-rustc handling from bootstrap.py
- Allow a custom `pattern` in `builder.unpack()`
- Only download rustc once another part of bootstrap depends on it.
This is somewhat necessary since the download functions rely on having a full
`Builder`, which isn't available until after config parsing finishes.
|
|
- The logic is now unified for all targets (wasm targets should also be supported now)
- Additional "symlink" files like `ld64` are eliminated
- lld-wrapper is used for propagating the correct lld flavor
- Cleanup "unwrap or exit" logic in lld-wrapper
|
|
This happened because the `SYSROOT` variable was set for `x test`, but not `x build`.
Set it consistently for both to avoid unnecessary rebuilds.
|
|
There were two fixes needed:
1. Use `top_stage` instead of `top_stage - 1`. There was a long and torturous comment about trying to match rustdoc's version, but it works better without the hard-coding than with.
2. Make sure that `ci-llvm/lib` is added to LD_LIBRARY_PATH. Previously the error index would be unable to load LLVM for stage0 builds.
At some point we should probably have a discussion about how rustdoc stages should be numbered;
confusion between 0/1/2 has come up several times in bootstrap now.
Note that this is still broken when using `download-rustc = true` and `--stage 1`,
but that's *really* a corner case and should affect almost no one. `--stage {0,2}`
work fine with download-rustc.
|
|
Fixes warnings from `clippy::useless_conversion` in `src/bootstrap`.
|
|
|
|
The majority of the code is only used by either rustbuild or
rustc_llvm's build script. Rust_build is compiled once for rustbuild and
once for every stage. This means that the majority of the code in this
crate is needlessly compiled multiple times. By moving only the code
actually used by the respective crates to rustbuild and rustc_llvm's
build script, this needless duplicate compilation is avoided.
|
|
As far as I can tell, this parameter was never used, so just delete it
as unnecessary.
|
