-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test tidy
should ignore alternative build
dir patterns
#84530
Conversation
I need to have multiple `build` directories, such as `build`, `build-fuchsia`, and `build-test`. But when I'm uploading a change, I run `./x.py test tidy`, and if I have a `build-something` directory with Rust sources, I git a bunch of formatting errors. `rustfmt.toml` only ignores the directory named `build`. This change extends the patterns to also ignore `build-*` and `*-build`. As a rustc contributor, I not only build the rust compiler to develop new features, but I also build alternative "distributions" (using secondary `*-config.toml` files with different configurations), including: * To occasionally rebuild a version of the compiler that `rust-analyzer` can use to `check` source (which fixes issues in the VS Code UI, so changing and rebuilding the compiler does not break VS Code editing Rust code). * To build custom distributions for Fuchsia * To build test distributions when working on changes to `bootstrap` (e.g., when I recently added `rust-demangler` to distributions)
(rust-highfive has picked a reviewer for you, use r? to override) |
@richkadel I'm curious - what's your workflow look like for those different build directories? Are you testing the same changes for multiple targets? Or are you switching between branches and you don't want to lose the build cache? For the second case I'd recommend git worktrees instead: https://rustc-dev-guide.rust-lang.org/building/suggested.html#working-on-multiple-branches-at-the-same-time |
It's the first case. For example, I normally build with debug, targeting only linux, and sometimes with a debug build of LLVM. But when testing with Fuchsia, I have to use a very specific set of |
@Mark-Simulacrum - Any questions or concerns here? (rust-highfive added you as reviewer. Let me know if you'd like someone else to review instead.) Thanks! |
I usually take several days to get to an initial review - unfortunately accumulated some backlog which I've been processing over the last several days, so hopefully will get to this soon. |
No problem and no rush. Thanks for letting me know. |
@bors r+ rollup Seems reasonable to me, thanks. Interesting pattern for sure! |
📌 Commit 79020a8 has been approved by |
…ark-Simulacrum `test tidy` should ignore alternative `build` dir patterns I need to have multiple `build` directories, such as `build`, `build-fuchsia`, and `build-test`. But when I'm uploading a change, I run `./x.py test tidy`, and if I have a `build-something` directory with Rust sources, I git a bunch of formatting errors. `rustfmt.toml` only ignores the directory named `build`. This change extends the patterns to also ignore `build-*` and `*-build`. As a rustc contributor, I not only build the rust compiler to develop new features, but I also build alternative "distributions" (using secondary `*-config.toml` files with different configurations), including: * To occasionally rebuild a version of the compiler that `rust-analyzer` can use to `check` source (which fixes issues in the VS Code UI, so changing and rebuilding the compiler does not break VS Code editing Rust code). * To build custom distributions for Fuchsia * To build test distributions when working on changes to `bootstrap` (e.g., when I recently added `rust-demangler` to distributions)
…ark-Simulacrum `test tidy` should ignore alternative `build` dir patterns I need to have multiple `build` directories, such as `build`, `build-fuchsia`, and `build-test`. But when I'm uploading a change, I run `./x.py test tidy`, and if I have a `build-something` directory with Rust sources, I git a bunch of formatting errors. `rustfmt.toml` only ignores the directory named `build`. This change extends the patterns to also ignore `build-*` and `*-build`. As a rustc contributor, I not only build the rust compiler to develop new features, but I also build alternative "distributions" (using secondary `*-config.toml` files with different configurations), including: * To occasionally rebuild a version of the compiler that `rust-analyzer` can use to `check` source (which fixes issues in the VS Code UI, so changing and rebuilding the compiler does not break VS Code editing Rust code). * To build custom distributions for Fuchsia * To build test distributions when working on changes to `bootstrap` (e.g., when I recently added `rust-demangler` to distributions)
Rollup of 11 pull requests Successful merges: - rust-lang#84484 (Don't rebuild rustdoc and clippy after checking bootstrap) - rust-lang#84530 (`test tidy` should ignore alternative `build` dir patterns) - rust-lang#84531 (Ignore commented out lines when finding features) - rust-lang#84540 (Build sanitizers for x86_64-unknown-linux-musl) - rust-lang#84555 (Set `backtrace-on-ice` by default for compiler and codegen profiles) - rust-lang#84585 (Add `x.py check src/librustdoc` as an alias for `x.py check src/tools/rustdoc`) - rust-lang#84636 (rustdoc: change aliases attribute to data-aliases) - rust-lang#84646 (Add some regression tests related to rust-lang#82494) - rust-lang#84661 (Remove extra word in `rustc_mir` docs) - rust-lang#84663 (Remove `DropGuard` in `sys::windows::process` and use `StaticMutex` instead) - rust-lang#84668 (Update books) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
I need to have multiple
build
directories, such asbuild
,build-fuchsia
, andbuild-test
. But when I'm uploading a change, Irun
./x.py test tidy
, and if I have abuild-something
directory withRust sources, I git a bunch of formatting errors.
rustfmt.toml
only ignores the directory namedbuild
.This change extends the patterns to also ignore
build-*
and*-build
.As a rustc contributor, I not only build the rust compiler to develop
new features, but I also build alternative "distributions" (using
secondary
*-config.toml
files with different configurations),including:
rust-analyzer
can use to
check
source (which fixes issues in the VS Code UI, sochanging and rebuilding the compiler does not break VS Code editing Rust
code).
bootstrap
(e.g., when I recently added
rust-demangler
to distributions)