-
Notifications
You must be signed in to change notification settings - Fork 13k
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
keep the root dir clean from debugging #65653
Conversation
(rust_highfive has picked a reviewer for you, use r? to override) |
I think having these in |
That was a bug. Adding them to
Why do you think they contradict? I wrote both of them and I think the one at the top implies the one at the bottom (which I added just as clarification and clearly because the one at the top is not enough). |
I agree with your description but I'm explicitly arguing for the unprincipled solution of using duct tape to alleviate some pain. :)
Maybe "contradict" is too strong. The first comment does suggest however that ignoring things generated in the build is something the file should do. The latter suggests something in the other direction. |
These files don't get generated by a normal build (if they do, it's a bug). They get generated by manually calling
The bug is fixed already so I really don't get it. Usually when we fix a bug we add a test to make sure it doesn't come back; you are now instead proposing to actively work towards not noticing regressions. On a somewhat more serious note, this is kind of comparable with In my years of working on Rust, this is the one and only time |
Ah, I was unaware of the policy we had set to not do this in the general case. I think it makes sense to remove the changes to .gitignore (as this PR does) -- I agree that they're papering over what seems to be (and should be) a non-existent problem in a non-ideal way. I feel similarly opposed/confused I think by @Centril's comment of "duct tape to alleviate some pain" since to our knowledge, there is no more pain anymore (and it should hopefully not arise, due to the tidy lint). r=me with nit fixed unless you want to wait for broader consensus |
Sorry for the churn. I was unaware of the previous discussions around this, and I didn't fully grok the reasoning for the comment at the top. |
@RalfJung I think there's a lot of reductio ad absurdum going on in your comment. Obviously I don't agree with ignoring
Since the bug has been fixed I'm fine with removing it from
That's not my experience, it has happened much more frequently for me (probably because I kill builds quickly sometimes). All in all I'm fine with this landing but I wanted to register that ignoring things for a while is useful sometimes. |
Nit is fixed but I'd prefer to clarify the wording if we can, so I did some more editing. @Centril I clarified that only the @ecstatic-morse how could we improve the comment to avoid repeating this exercise? |
Not reductio ad absurdsum but consistently applying the standards you seem to have for file system cleanliness to other things. I did not expect you to actually agree with any of the other cases, obviously -- but I wanted to point out that those all are different flavors of the same principle for me. Because you care about having a clean codebase, I thought you might have some empathy for people that have similarly strong feelings for having a clean file system. |
That's fair enough. I do see the value of a clean file system (but there are benefits on the other side too). |
@bors r=Mark-Simulacrum,Centril rollup |
📌 Commit ebc9a1a has been approved by |
I meant more that it wasn't worded very strongly, unlike the new comment. I skimmed it thinking it was a generic description of what |
…um,Centril keep the root dir clean from debugging We landed this before with rust-lang#63307 but recently in rust-lang#65630 the IMO bad ignore crept back in. If you regularly do graphviz-based debugging and you are fine leaving junk in the rustc root dir, please configure your local `.git/info/exclude`. But most people working on rustc don't work with graphciz all that often (I for once never did), and not everyone likes to have stray generated files in their source dirs. Also Cc rust-lang#63373 rust-lang#53768 @ecstatic-morse @Mark-Simulacrum
…um,Centril keep the root dir clean from debugging We landed this before with rust-lang#63307 but recently in rust-lang#65630 the IMO bad ignore crept back in. If you regularly do graphviz-based debugging and you are fine leaving junk in the rustc root dir, please configure your local `.git/info/exclude`. But most people working on rustc don't work with graphciz all that often (I for once never did), and not everyone likes to have stray generated files in their source dirs. Also Cc rust-lang#63373 rust-lang#53768 @ecstatic-morse @Mark-Simulacrum
Rollup of 7 pull requests Successful merges: - #62330 (Change untagged_unions to not allow union fields with drop) - #65092 (make is_power_of_two a const function) - #65621 (miri: add write_bytes method to Memory doing bounds-checks and supporting iterators) - #65647 (Remove unnecessary trait bounds and derivations) - #65653 (keep the root dir clean from debugging) - #65660 (Rename `ConstValue::Infer(InferConst::Canonical(..))` to `ConstValue::Bound(..)`) - #65663 (Fix typo from #65214) Failed merges: r? @ghost
We landed this before with #63307 but recently in #65630 the IMO bad ignore crept back in.
If you regularly do graphviz-based debugging and you are fine leaving junk in the rustc root dir, please configure your local
.git/info/exclude
. But most people working on rustc don't work with graphciz all that often (I for once never did), and not everyone likes to have stray generated files in their source dirs.Also Cc #63373 #53768 @ecstatic-morse @Mark-Simulacrum