Split tests/ieee.rs into smaller files

[yerke]

Part of #60302

[rust-highfive]

Changes rustc_apfloat. rustc_apfloat is currently in limbo and you almost certainly don't want to change it (see #55993).

cc @eddyb

[rust-highfive]

r? @nagisa

(rust-highfive has picked a reviewer for you, use r? to override)

[nagisa]

This seems like a reasonable thing to do, but I'm not sure if splitting into numbered files is the right approach. At the very least I would like to see more meaningful file/module names and grouping.

Another concern I have is that a change such as this will cause, if I recall correctly, the build system to link multiple test binaries, thus increasing build times. I feel like these tests should be moved from integration tests back into the in-library #[test] modules.

[eddyb]

r? @eddyb

Splitting files up just for the sake of it doesn't make sense to me. There's nothing inherently bad about long files, only about lack of organization, and just splitting the files up doesn't introduce more organization. The tidy check is merely a poor approximation of a vague metric, not some kind of golden rule.

As anecdotal evidence, I've never really run into issues with very long files, but have had time wasted by unexpected "this part of the code is in some other random place I didn't expect to exist".

Also, organization mostly matters for areas of active development. rustc_apfloat is quite the opposite of that.

In fact, you can consider rustc_apfloat to be in minimal-maintenance mode (see also #55993). As such, PRs that are not required to keep the build working, should probably not be accepted. The only exception I can think of is if you can find some additional organization in LLVM that could be replicated here (but I'm also wary about backports given the whole licensing stuff).

[workingjubilee]

ieee2.rs is an interesting choice of name, at the very least, when the ieee part is short for "IEEE 754-2008", I believe, which is indeed the 2nd revision of the standard, but both of these would be testing conformance to that...

[yerke]

@eddyb The motivation to get rid of // ignore-tidy-filelength was described in #60302, which I linked in the description.
Do you want me to close this PR?