Add error message when cargo fix on an empty repo

[Rustin170506]

What does this PR try to resolve?

close #11380

Add error message when cargo fix on an empty repo.

How should we test and review this PR?

• unit test

set -eux

cargo +nightly new repro
cd repro
echo "fn main() { let _ = 0.clone(); }" > src/main.rs
cargo fix

[rustbot]

r? @epage

(rustbot has picked a reviewer for you, use r? to override)

[epage]

@bors r+

We are expanding our check but I do not think this would break a workflow to be considered a breaking change.

I am somewhat concerned about this complaining about editor temp files and such when a user hasn't configured their personal gitignore. If we push people to use --allow-dirty too much, then they will likely miss important things. However, the only good idea I had here was limiting the check to cargo package --list but I assume that most implicit or explicitly configured lists of files will still include these untracked files .

We do have other issues that could improve the dirty workflow overall though,

So I figure we can go ahead with this.

[bors]

📌 Commit 21b2fe9 has been approved by epage

It is now in the queue for this repository.

[bors]

⌛ Testing commit 21b2fe9 with merge a2ea66b...

[bors]

☀️ Test successful - checks-actions
Approved by: epage
Pushing a2ea66b to master...

[bryanlarsen]

@bors r+

We are expanding our check but I do not think this would break a workflow to be considered a breaking change.

I am somewhat concerned about this complaining about editor temp files and such when a user hasn't configured their personal gitignore. If we push people to use --allow-dirty too much, then they will likely miss important things. However, the only good idea I had here was limiting the check to cargo package --list but I assume that most implicit or explicitly configured lists of files will still include these untracked files .

We do have other issues that could improve the dirty workflow overall though,

So I figure we can go ahead with this.

I'm one with a broken workflow. I should probably clean up my untracked files, but the broken workflow was jarring...

Perhaps an --allow-untracked flag? That would be much less dangerous than training people to use --allow-dirty