Rename AtomicInt and AtomicUint

[sfackler]

Change any use of AtomicInt to AtomicIsize and AtomicUint to AtomicUsize

Closes #20893

[breaking-change]

[rust-highfive]

r? @alexcrichton

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

[sfackler]

cc @aturon These may be able to be stabilized now?

[alexcrichton]

Thanks! I'm fine marking these as #[stable] now that the fallout of the integer discussions has become more clear. I'd like @aturon to second that, however.

Could you also retain the old AtomicInt/AtomicUint types entirely in order to smooth over migration? I think we're going to try to fairly aggressively try to smooth transitions during this release cycle. Unfortunately a pub use won't actually trigger deprecation warnings, so an entire duplication will be needed, but that's not too too bad so long as the documentation is all deleted!

[sfackler]

@alexcrichton updated

[aturon]

Thanks @sfackler, already picking off items from my post-alpha TODO :) I'm fine with this.

(AtomicIsize looks weird, but I'm sure I'll get over it.)

[aidancully]

Just saw this from This-Week-In-Rust. This won't be a big deal in practice, but this change creates the mis-implication that pointer-width (which is the basis of isize and usize) is the same size as the memory data bus (which is the number of bits that can be read-from and written-to atomically). There is no such necessary relationship, it is possible to have a 64-bit pointer width and an 8-bit data bus, in which case the 64-bit write would be translated into 8 memory transactions by the CPU. It turns out that the numbers are the same on most platforms (based on http://www.gnu.org/software/libc/manual/html_node/Atomic-Types.html), so this implication shouldn't generally cause issues, but it's worth noting.