Make target dir self-ignoring

[senekor]

Fixes #15061

How to test:

• run cargo new, observer that no .gitignore is generated
• run cargo build, observe that git still ignores the target directory
• run cargo build with different ways to override the default target directory location:
  • CLI arg (--target-dir)
  • environment variable (CARGO_TARGET_DIR)
  • .cargo/config.toml: build.target-dir

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @epage (or someone else) some time within the next two weeks.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[senekor]

This is currently a proof of concept, meant as a starting point for discussing how to implement it properly.

The easy approach is to just make sure that the gitignore file exists whenever the target directory path is determined.
This leads to some (maybe unacceptable) quirks.
For example, many cargo commands would touch the file system when the user doesn't expect it (even cargo clean --dry-run creates the gitignore file).

[epage]

Note that #11548 is not labeled with S-accepted which is a prerequisite for being reviewed, see https://doc.crates.io/contrib/process/working-on-cargo.html

[senekor]

makes sense!

[senekor]

I removed the part dealing with cargo new. The PR now points to #15061, which reflects the smaller scope. (approval still pending)

[joshtriplett]

I love this idea.

[senekor]

Note that I changed the implementation here. I previously created the .gitignore file every time a workspace's target_dir was queried. This doesn't seem very clean and lead to actual weirdness. For example, cargo clean would always create the target directory and .gitignore file, then delete them again.

After poking around in the cargo code a little more, I discovered create_dir_all_excluded_from_backups_atomic, which seemed like the perfect place to add this functionality. After all, version control can be considered a form of backup. Turns out that function works very similarly already: It creates a "CACHEDIR.TAG" file with a specific content.

So, I simply added my code as an additional step in that function. I hope this should be correct and maintainable.

[rustbot]

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.