Misc: better instructions for envrc, ignore /build instead of build/ by WaffleLapkin · Pull Request #133592 · rust-lang/rust (original) (raw)
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 andprivacy statement. We’ll occasionally send you account related emails.
Already on GitHub?Sign in to your account
Conversation5 Commits3 Checks6 Files changed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.Learn more about bidirectional Unicode characters
[ Show hidden characters]({{ revealButtonHref }})
See commits for more information.
r? @jieyouxu
This comment has been minimized.
Previous setup instructions did not work without. (i.e. the envrc would
not do anything, nix flake show.. would provide unhelpful error)
this does two things:
- allows making
builda symlink (which is not considered a directory by git, thus removal of trailing/). - removes the need to special case
rustc_mir_build/src/build(leading/makes git only ignore thebuildin the root)
this is funny though! apparently tidy parsed .gitignore, but did not
recognize unignore lines (!...), so tidy was ignoring rustc_mir_build
this whole time (at least for some lints?).
Relevant to the compiler team, which will review and decide on the PR/issue.
label
this is funny though! apparently tidy parsed
.gitignore, but did not recognize unignore lines (!...), so tidy was ignoringrustc_mir_buildthis whole time (at least for some lints?).
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
FYI @pnkfelix since you expressed previously that you wanted to run ./x from within subdirectories, and this will modify the gitignore behavior such that it might regress such workflow. However, having gitignore need to ignore directories named build/ but then also using a negated rule to skip the mir build module (not properly supported by many tools incl. github ui and tidy) makes this really weird.
If you still really need to preserve that workflow, you can explicitly specify the build directory location via config.toml.
Thus, I'm inclined to only ignore /build directory from checkout source root and not any further subdirectories.
@bors r+ rollup
📌 Commit 8e77349 has been approved by jieyouxu
It is now in the queue for this repository.
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
and removed S-waiting-on-review
Status: Awaiting review from the assignee but also interested parties.
labels
Zalathar added a commit to Zalathar/rust that referenced this pull request
Misc: better instructions for envrc, ignore /build instead of build/
See commits for more information.
r? @jieyouxu
bors added a commit to rust-lang-ci/rust that referenced this pull request
bors added a commit to rust-lang-ci/rust that referenced this pull request
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#133592 - WaffleLapkin:misc-meowing, r=jieyouxu
Misc: better instructions for envrc, ignore /build instead of build/
See commits for more information.
r? @jieyouxu
jhpratt added a commit to jhpratt/rust that referenced this pull request
Rename rustc_mir_build::build to builder
GitHub's “Go to file” feature silently ignores all files in this module, presumably because they are in a directory named build, which is mistaken for a build-output directory. That makes it meaningfully harder to view those files and their history via GitHub.
This PR sidesteps that issue by renaming build to builder, which in context has basically the same meaning, but can't be mistaken for a build-output directory.
Extracted from rust-lang#133404, after rust-lang#133592 changed the .gitignore rule from build/ to /build. The problem of GitHub ignoring these files still exists even after that change, which suggests that GitHub's behaviour is a hard-coded heuristic that isn't influenced by the repository's git settings.
Currently this PR doesn't include the tidy rule forbidding build as a module name, but that could be added if people think it's a good idea.
jhpratt added a commit to jhpratt/rust that referenced this pull request
Rename rustc_mir_build::build to builder
GitHub's “Go to file” feature silently ignores all files in this module, presumably because they are in a directory named build, which is mistaken for a build-output directory. That makes it meaningfully harder to view those files and their history via GitHub.
This PR sidesteps that issue by renaming build to builder, which in context has basically the same meaning, but can't be mistaken for a build-output directory.
Extracted from rust-lang#133404, after rust-lang#133592 changed the .gitignore rule from build/ to /build. The problem of GitHub ignoring these files still exists even after that change, which suggests that GitHub's behaviour is a hard-coded heuristic that isn't influenced by the repository's git settings.
Currently this PR doesn't include the tidy rule forbidding build as a module name, but that could be added if people think it's a good idea.
rust-timer added a commit to rust-lang-ci/rust that referenced this pull request
Rollup merge of rust-lang#134365 - Zalathar:builder, r=nnethercote
Rename rustc_mir_build::build to builder
GitHub's “Go to file” feature silently ignores all files in this module, presumably because they are in a directory named build, which is mistaken for a build-output directory. That makes it meaningfully harder to view those files and their history via GitHub.
This PR sidesteps that issue by renaming build to builder, which in context has basically the same meaning, but can't be mistaken for a build-output directory.
Extracted from rust-lang#133404, after rust-lang#133592 changed the .gitignore rule from build/ to /build. The problem of GitHub ignoring these files still exists even after that change, which suggests that GitHub's behaviour is a hard-coded heuristic that isn't influenced by the repository's git settings.
Currently this PR doesn't include the tidy rule forbidding build as a module name, but that could be added if people think it's a good idea.
Labels
Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Relevant to the compiler team, which will review and decide on the PR/issue.