| Age | Commit message (Collapse) | Author | Lines |
|---|
|
(cherry picked from commit f13edeb4514368b4b3748e8f437fd6a166d95aff)
|
|
bootstrap: Document `struct Builder` and its fields
I'm exploring the code of bootstrap and had a bit of a hard time understanding exactly what `Builder` is for at first. I decided to help document it and its field to help future explorers.
|
|
r=Mark-Simulacrum
bootstrap: Describe build_steps modules
One of my preferred ways to understand source code is to start with its API. This implies the code is documented reasonably accurately, even if it is a private API. The description of one of these modules had not been updated since 2015 and so was both terse and confusing, so I rewrote it. Then I noticed many others went unremarked, so I offered some remarks.
|
|
`x vendor`
This PR implements `x vendor` on bootstrap; enabling dependency vendoring without the need for developers to have `cargo` installed on their system (previously, we suggested running `cargo vendor ...` but now we can accomplish the same task with `x vendor`).
In addition, fixes #112391 problem.
|
|
Rollup of 7 pull requests
Successful merges:
- #124370 (Fix substitution parts having a shifted underline in some cases)
- #124394 (Fix ICE on invalid const param types)
- #124425 (Do not ICE on invalid consts when walking mono-reachable blocks)
- #124434 (Remove lazycell and once_cell from compiletest dependencies)
- #124437 (doc: Make the `mod.rs` in the comment point to the correct location)
- #124443 (Elaborate in comment about `statx` probe)
- #124445 (bootstrap: Change `global(true)` to `global = true` for flags for consistency)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
bootstrap: Change `global(true)` to `global = true` for flags for consistency
All other arg properties use the `prop = value` style, which makes it slightly annoying to use the `prop(value)` only style for `global`. Change to `prop = value` also for `global` for consistency.
|
|
miri core/alloc tests: do not test a 2nd target
check-aux seems to be one of the slowest runners since we started running standard library tests in Miri on it. So maybe it'd be better to reduce test coverage a bit by not doing cross-target testing of core and alloc? I don't recall finding target-specific issues in these libraries ever (and we still have the extra test coverage via our [out-of-tree nightly tests](https://github.com/rust-lang/miri-test-libstd)). This gives us more buffer to deal with the fact that the number of tests we run will only grow over time.
Cc `@rust-lang/miri` `@rust-lang/infra`
|
|
All other arg properties use the `prop = value` style, which makes it
slightly annoying to use the `prop(value)` style for `global`. Change to
`prop = value` also for `global` for consistency.
|
|
|
|
bootstrap: keep all cargo test files in dist rustc-src
Cargo tests use some files that we would otherwise exclude, especially
the `cargo init` tests that are meant to deal with pre-existing `.git`
and `.hg` repos and their ignore files. Keeping these in our dist
tarball doesn't take much space, and allows distro builds to run these
tests successfully.
|
|
|
|
Co-authored-by: Onur Özkan <onurozkan.dev@outlook.com>
|
|
Fix some typos in comments
|
|
Signed-off-by: TechVest <techdashen@qq.com>
|
|
|
|
|
|
Cargo tests use some files that we would otherwise exclude, especially
the `cargo init` tests that are meant to deal with pre-existing `.git`
and `.hg` repos and their ignore files. Keeping these in our dist
tarball doesn't take much space, and allows distro builds to run these
tests successfully.
|
|
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The description was most accurate when it was still called rustbuild,
and I presume indeed did mostly run in CI. It has become something more
so try to describe it better for current-day usage.
|
|
enable clippy for bootstrap on CI PRs (in `mingw-check` image)
Let's keep the bootstrap codebase cleaner.
|
|
bootstrap: don't use rayon for sysinfo
It's looks overkill to use rayon to collect cpu usage
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
bootstrap: actually allow set debuginfo-level to "line-tables-only"
I've tried to set in config.toml `rust.debuginfo-level = "line-tables-only"`, but ended with:
``` failed to parse TOML configuration 'config.toml':
data did not match any variant of untagged enum StringOrInt for key `rust.debuginfo-level`
```
Also this PR allows to set `line-directives-only` for debuginfo in config.toml too.
1. Fixes this. Alternative is remove that Deserialize and use default one:
https://github.com/rust-lang/rust/blob/0e682e9875458ebf811206a48b688e07d762d9bb/src/bootstrap/src/core/config/config.rs#L725-L728
2. Should `line-directives-only` be added too?
3. I've tried to add test to rust/src/bootstrap/src/core/config/tests.rs:
```rust
#[test]
fn rust_debuginfo() {
assert!(matches!(
parse("rust.debuginfo-level-rustc = 1").rust_debuginfo_level_rustc,
DebuginfoLevel::Limited
));
assert!(matches!(
parse("rust.debuginfo-level-rustc = \"line-tables-only\"").rust_debuginfo_level_rustc,
DebuginfoLevel::LineTablesOnly
));
}
```
But test passes before that PR too; looks like config parse tests checks something wrong? I mean, that tests check something which isn't actual bootstrap behavior.
|
|
It's looks overkill to use rayon to collect cpu usage
|
|
Co-authored-by: Onur Özkan <onurozkan.dev@outlook.com>
|
|
|
|
Update how WASI toolchains are used in CI and bootstrap
This commit updates how the WASI targets are configured with their toolchain. Long ago a `config.toml` option of `wasi-root` was added to enable building with the WASI files produced by wasi-libc. Additionally for CI testing and release building the Rust toolchain has been using a hard-coded commit of wasi-libc which is bundled with the release of the `wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is the go-to solution for compiling/linking WASI code and contains the more-or-less official releases of wasi-libc. This commit migrates CI to using wasi-sdk releases and additionally updates `bootstrap` to recognize when this is configured. This means that with `$WASI_SDK_PATH` configured there's no further configuration necessary to get a working build. Notably this also works better for the new targets of WASI as well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the wasi-sdk release now has libraries for all targets bundled within it.
|
|
|
|
|
|
refactor clippy in bootstrap
Previously, using clippy in bootstrap was not very useful as explained in #122825. In short, regardless of the given path clippy would always check the entire compiler and std tree. This makes it impossible to run clippy on different paths with different set of rules. This PR fixes that by allowing developers to run clippy with specific rules on specific paths (e.g., we can run `x clippy compiler -Aclippy::all -Dclippy::correctness` and `x clippy library/std -Dclippy::all` and none of them will affect each other).
Resolves #122825
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
drop `changelog-seen`
It's been 7 months since we deprecated this. It should be fine to remove it now.
|
|
fetch submodule before checking llvm stamp
Previously, we were checking the LLVM stamp before fetching the submodule which leads to not being able to compile llvm on submodule updates.
Fixes #122612
Fixes #122787
|
|
doc(bootstrap): add top-level doc-comment to utils/tarball.rs
|
|
This commit updates how the WASI targets are configured with their
toolchain. Long ago a `config.toml` option of `wasi-root` was added to
enable building with the WASI files produced by wasi-libc. Additionally
for CI testing and release building the Rust toolchain has been using a
hard-coded commit of wasi-libc which is bundled with the release of the
`wasm32-wasip1` target, for example.
Nowadays though the wasi-sdk project, the C/C++ toolchain for WASI, is
the go-to solution for compiling/linking WASI code and contains the
more-or-less official releases of wasi-libc. This commit migrates CI to
using wasi-sdk releases and additionally updates `bootstrap` to
recognize when this is configured. This means that with `$WASI_SDK_PATH`
configured there's no further configuration necessary to get a working
build. Notably this also works better for the new targets of WASI as
well, such as `wasm32-wasip2` and `wasm32-wasip1-threads` where the
wasi-sdk release now has libraries for all targets bundled within it.
|
