| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Previously they were using `all_krates` and various hacks to determine
which crates to document. Switch them to `crate_or_deps` so `ShouldRun`
tells them which crate to document instead of having to guess.
This also makes a few other refactors:
- Remove the now unused `all_krates`; new code should only use
`crate_or_deps`.
- Add tests for documenting Std
- Remove the unnecessary `run_cargo_rustdoc_for` closure so that we only
run cargo once
- Give a more helpful error message when documenting a no_std target
- Use `builder.msg` in the Steps instead of `builder.info`
|
|
Previously `description` only supported `Testing` and `Benchmarking`,
and `msg` gave weird results for `doc` (it would say `Docing`).
|
|
Before:
```
thread 'main' panicked at 'no entry found for key', builder.rs:110:30
```
After:
```
thread 'main' panicked at 'missing crate for path library', check.rs:89:26
```
|
|
r=albertlarsan68,oli-obk
new tool `rustdoc-gui-test`
Implements new tool `rustdoc-gui-test` that allows using compiletest headers for `rustdoc-gui` tests.
|
|
Make errors from `x doc` less verbose
before:
```
error: could not document `bootstrap`
Caused by:
process didn't exit successfully: `/home/jyn/src/rust/build/bootstrap/debug/rustdoc ... --crate-version '1.71.0
(eb9da7bfa
2023-05-25)
(a
long
description
goes
here)' --document-private-items --enable-index-page --show-type-layout --generate-link-to-definition -Zunstable-options` (exit status: 1)
```
after:
```
error: could not document `bootstrap`
Caused by:
process didn't exit successfully: `/home/jyn/src/rust/build/bootstrap/debug/rustdoc ... --crate-version '1.71.0 (eb9da7bfa 2023-05-25) (a long description goes here)' --document-private-items --enable-index-page --show-type-layout --generate-link-to-definition -Zunstable-options` (exit status: 1)
```
|
|
before:
```
error: could not document `bootstrap`
Caused by:
process didn't exit successfully: `/home/jyn/src/rust/build/bootstrap/debug/rustdoc ... --crate-version '1.71.0
(eb9da7bfa
2023-05-25)
(a
long
description
goes
here)' --document-private-items --enable-index-page --show-type-layout --generate-link-to-definition -Zunstable-options` (exit status: 1)
```
after:
```
error: could not document `bootstrap`
Caused by:
process didn't exit successfully: `/home/jyn/src/rust/build/bootstrap/debug/rustdoc ... --crate-version '1.71.0 (eb9da7bfa 2023-05-25) (a long description goes here)' --document-private-items --enable-index-page --show-type-layout --generate-link-to-definition -Zunstable-options` (exit status: 1)
```
|
|
This reverts commit 827f656ebb1230f31af6d968c4bfe69a79914ffc.
Incremental is not sound to use across stages. Arbitrary changes to the compiler can invalidate the
incremental cache - even changes to normal queries, not incremental itself! - and we do not
currently enable `incremental-verify-ich` in bootstrap. Since 2018, we highly recommend and nudge
users towards stage 1 builds instead of stage 2, and using `keep-stage` for anything other than
libstd is very rare.
I don't think the risk of unsoundness is worth the very minor speedup when building libstd. Disable
incremental to avoid spurious panics and miscompilations when building with the stage 1 and 2
sysroot.
|
|
This verifies the intra-doc links are correct, and hopefully makes
things easier for new contributors.
|
|
|
|
- add `must_use` to `early_error_no_abort`
this was already being used at its only callsite, but this ensures
that new code remembers to use it if it's called in the future.
- remove outdated and incorrect comment in `builder.rs`.
`doc_rust_lang_org_channel` doesn't exist in rustdoc, it gets it from
an env var instead.
|
|
Generate shell completions for bootstrap with Clap
Now that #110693 has been merged, we can look at generating shell completions for x.py with `clap_complete`. Leaving this as draft for now as I'm not sure of the best way to integration the completion generator. Additionally, the generated completions for zsh are completely broken (will need to be resolved upstream, it doesn't seem to handle subcommands + global arguments well).
I don't have Fish installed and would be interested to know how well completions work there.
Alternative to #107827
|
|
|
|
r=albertlarsan68
support set `rpath` option for each target independently
Currently the `rpath` option is a global config and it's effect on all targets.
But sometimes when developers edit the rustc code and try to release rust toolchains themselves, they may not want to add `rpath` in all targets to avoid dynamically linked shared object library privilege escalation attack.
This PR supports set `rpath` option for each target independently .
Common developers are not aware of the existence of this configuration option and do not affect the existing development process. This configuration option takes effect only after developers explicitly sets .
r? ``@albertlarsan68``
|
|
Start using `windows sys` for Windows FFI bindings in std
Switch to using windows-sys for FFI. In order to avoid some currently contentious issues, this uses windows-bindgen to generate a smaller set of bindings instead of using the full crate.
Unlike the windows-sys crate, the generated bindings uses `*mut c_void` for handle types instead of `isize`. This to sidestep opsem concerns about mixing pointer types and integers between languages. Note that `SOCKET` remains defined as an integer but instead of being a usize, it's changed to fit the [standard library definition](https://github.com/rust-lang/rust/blob/a41fc00eaf352541008965fec0dee811e44373b3/library/std/src/os/windows/raw.rs#L12-L16):
```rust
#[cfg(target_pointer_width = "32")]
pub type SOCKET = u32;
#[cfg(target_pointer_width = "64")]
pub type SOCKET = u64;
```
The generated bindings also customizes the `#[link]` imports. I hope to switch to using raw-dylib but I don't want to tie that too closely with the switch to windows-sys.
---
Changes outside of the bindings are, for the most part, fairly minimal (e.g. some differences in `*mut` vs. `*const` or a few types differ). One issue is that our own bindings sometimes mix in higher level types, like `BorrowedHandle`. This is pretty adhoc though.
|
|
r=Mark-Simulacrum
enable `rust_2018_idioms` lint group for doctests
With this change, `rust_2018_idioms` lint group will be enabled for compiler/libstd doctests.
Resolves #106086
Resolves #99144
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
|
|
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
|
|
|
|
|
|
|
|
|
|
Spelling src bootstrap
The various src/* items seem slightly disparate, so I'm doing src/* individually.
split from #110392
|
|
Support `x test --stage 1 ui-fulldeps`
`@Nilstrieb` had an excellent idea the other day: the same way that rustdoc is able to load `rustc_driver` from the sysroot, ui-fulldeps tests should also be able to load it from the sysroot. That allows us to run fulldeps tests with stage1, without having to fully rebuild the compiler twice. It does unfortunately have the downside that we're building the tests with the *bootstrap* compiler, not the in-tree sources, but since most of the fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of the running compile to match the ABI of the compiler linked with `rustc_driver`. As a result they can't be supported in stage 1 and have to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage 2 build to load rustc_driver, it's primarily testing the error message that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That allows running `hash-stable-is-unstable` in stage1, since it now suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the correct version of std.
- Move a few lint tests from ui-fulldeps to ui
These had an `aux-build:lint-group-plugin-test.rs` that they never actually loaded with `feature(plugin)` nor tested. I removed the unused aux-build and they pass fine with stage 1.
Fixes https://github.com/rust-lang/rust/issues/75905.
|
|
Avoid including dry run steps in the build metrics
Including steps executed during the dry run will result in a duplication of all the steps in the build metrics, which just adds noise.
|
|
Nils had an excellent idea the other day: the same way that rustdoc is
able to load `rustc_driver` from the sysroot, ui-fulldeps tests should
also be able to load it from the sysroot. That allows us to run fulldeps
tests with stage1, without having to fully rebuild the compiler twice.
It does unfortunately have the downside that we're running the tests on
the *bootstrap* compiler, not the in-tree sources, but since most of the
fulldeps tests are for the *API* of the compiler, that seems ok.
I think it's possible to extend this to `run-make-fulldeps`, but I've
run out of energy for tonight.
- Move `plugin` tests into a subdirectory.
Plugins are loaded at runtime with `dlopen` and so require the ABI of
the running compile to match the ABI of the compiler linked with
`rustc_driver`. As a result they can't be supported in stage 1 and have
to use `// ignore-stage1`.
- Remove `ignore-stage1` from most non-plugin tests
- Ignore diagnostic tests in stage 1. Even though this requires a stage
2 build to load rustc_driver, it's primarily testing the error message
that the *running* compiler emits when the diagnostic struct is malformed.
- Pass `-Zforce-unstable-if-unmarked` in stage1, not just stage2. That
allows running `hash-stable-is-unstable` in stage1, since it now
suggests adding `rustc_private` to enable loading the crates.
- Add libLLVM.so to the stage0 target sysroot, to allow fulldeps tests
that act as custom drivers to load it at runtime.
- Pass `--sysroot stage0-sysroot` in compiletest so that we use the
correct version of std.
|
|
* although
* correct
* granular
* libunwind
* repository
* section
Signed-off-by: Josh Soref <2119212+jsoref@users.noreply.github.com>
|
|
Including steps executed during the dry run will result in a duplication
of all the steps in the build metrics, which just adds noise.
|
|
|
|
This commit resolves an internal FIXME note within the bootstrap by implementing submodule detection.
This is accomplished through an iterative process over the `.gitmodules` file.
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
r=Mark-Simulacrum
Rename 'src/bootstrap/native.rs' to llvm.rs
Fixed #108240
Renamed 'native.rs' to 'llvm.rs', also moved `TestHelpers` to `test.rs`. Replaced all the `native.rs` occurrences at `src/bootstrap` files to `llvm.rs`
|
|
Permit the MIR inliner to inline diverging functions
This heuristic prevents inlining of `hint::unreachable_unchecked`, which in turn makes `Option/Result::unwrap_unchecked` a bad inlining candidate. I looked through the changes to `core`, `alloc`, `std`, and `hashbrown` by hand and they all seem reasonable. Let's see how this looks in perf...
---
Based on rustc-perf it looks like this regresses ctfe-stress, and the cachegrind diff indicates that this regression is in `InterpCx::statement`. I don't know how to do any deeper analysis because that function is _enormous_ in the try toolchain, which has no debuginfo in it. And a local build produces significantly different codegen for that function, even with LTO.
|
|
Renamed 'native.rs' to 'llvm.rs', also moved `TestHelpers` to `test.rs`.Replaced all the `native.rs` ocurrences at `src/bootstrap` files to `llvm.rs`
|
|
|
|
refactor `fn bootstrap::builder::Builder::compiler_for` logic
- check compiler stage before forcing for stage2.
- check if download_rustc is not set before forcing for stage1.
resolves #109286
|
|
|
|
|
|
- check compiler stage before forcing for stage2.
- check if download_rustc is not set before forcing for stage1.
Signed-off-by: ozkanonur <work@onurozkan.dev>
|
|
bootstrap: document tidy
Enable documentation of tidy, as suggested in #106803. Jyn mentioned they should probably be added to `doc.rust-lang.org`, how should that be done?
|
|
|
|
Set `LIBC_CHECK_CFG=1` when building Rust code in bootstrap
Downstream forks of the Rust compiler might want to use a custom `libc` to add support for targets that are not yet available upstream. Adding a patch to replace `libc` with a custom one would cause compilation errors though, because Cargo would interpret the custom `libc` as part of the workspace, and apply the check-cfg lints on it.
Since https://github.com/rust-lang/libc/pull/3037, the `libc` build script emits check-cfg flags only when the `LIBC_CHECK_CFG` environment variable is set, so this PR allows the use of custom `libc`s.
|
|
|
|
Import rust-installer & adjust compression settings
This brings in rust-lang/rust-installer#123, which enables a larger compression window (8 -> 64MB) amongst other changes to the xz compression settings. The net effect should be smaller compressed tarballs which will decrease bandwidth usage for
static.rust-lang.org, download times, and decompression time.
This comes at the cost of higher baseline requirements for running rustup to use these files, which we believe should be largely acceptable (running rustc is likely to use at least this much memory) but if we get specific reports we may explore options to decrease impact (e.g., using the gzip tarballs automatically in rustup).
To simplify iteration on compression settings this also imports the rust-lang/rust-installer submodule, it is now hosted fully inside rust-lang/rust. Once we land this I'll file a followup to add a note to that repo and we can subsequently archive it.
--
CI times for dist-x86_64-linux builds:
* threads=6, master - 2h 50m
* threads=1, new - 3h 40m
* threads=6, new - 2h 50m
|
|
config.download_rustc is set
|
|
|
|
Split `x setup` sub-actions to CLI arguments
Closes #107846
This adds a new `none` profile option which simply skips the `config.toml` step. It also adds `hook` and `vscode` subcommands, for installing the pre-push hook and getting `settings.json` respectively.
|
|
|
|
Most tests involving save-analysis were removed, but I kept a few where
the `-Zsave-analysis` was an add-on to the main thing being tested,
rather than the main thing being tested.
For `x.py install`, the `rust-analysis` target has been removed.
For `x.py dist`, the `rust-analysis` target has been kept in a
degenerate form: it just produces a single file `reduced.json`
indicating that save-analysis has been removed. This is necessary for
rustup to keep working.
Closes #43606.
|
|
|
|
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).
|
