tidy: stop special-casing tests/ui entry limit

[workingjubilee]

It is genuinely more annoying to have this error, now that this value is below the general ENTRY_LIMIT cap, when one is trying to clean out tests from tests/ui! This code has served its purpose well, let it rest now rather than force it to continue haunting us.

[rustbot]

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[workingjubilee]

I submit the fact #125310 conflicted with this, as does #125339, as evidence towards this.

[jackh726]

I think the entire point is that we want no tests in the root directory, not the same limit as other directories.

So, from that sense, this PR stops forcing us to monotonically decrease the number of tests there.

[workingjubilee]

@jackh726 That is not the work-item described by #73494 (comment)

That is also not what this lint enforces: if you remove all tests from tests/ui, including .rs, .stderr, .stdout, and .fixed files, the mismatched-number error yields the following error:

tidy error: `ROOT_ENTRY_LIMIT` is too high (is 757, should be 316)

Each directory is also an entry.

I am agreeable to adding a further restriction in a future PR, but my precise point is that right now, it actually adds overhead to reducing the number further. I cannot, for instance, subdivide moving items out into multiple PRs, if a given choice re: information architecture seems like it might be worth separate discussion. They will all conflict with each other. So I might as well only have one PR open.

[workingjubilee]

Not being able to personally subdivide might seem like a minor inconvenience, but this also prevents, say, making a megaissue that would probably clean up the last ~400 (non-directory) entries fairly quickly by turning them into ~200 checkboxes of "please make a directory or find a directory this belongs in". People like categorizing things and checking boxes.

I cannot, because they'd all conflict with each other, even if they successfully coordinated to avoid moving the same tests. Which is fairly doable, with only a few colliding elbows or stomped feet (figuratively speaking). However, making them all learn what git rebase -i is and how to do it correctly and then have each of them do it 10 times seems like a torment I cannot in good conscience inflict on people by such trickery.

[Mark-Simulacrum]

@bors r+

I'm going to go ahead and approve since it's easy-ish to revert and does seem to cause real annoyance even when moving in the "right" direction.

[bors]

📌 Commit d0b45a9 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

[fmease]

@bors rollup