Allow Atomics of pointer types

[HertzDevil]

This is needed for things like Atomic(LibC::HANDLE) (see #14389).

[straight-shoota]

Specs are (still) failing

[HertzDevil]

The failure happens when compiling spec/std/atomic_spec.cr and spec/std/xml/reader_spec.cr together on Crystal 1.2 or below. Reduction:

require "spec"
require "xml"

describe Atomic do
  describe "#compare_and_set" do
    it "with pointer" do
      atomic = Atomic.new(Pointer(Void).null)
      atomic.get.should eq(Pointer(Void).null)
    end
  end
end

module XML
  describe Reader do
    describe "#to_unsafe" do
      it "returns a pointer to the underlying LibXML::XMLTextReader" do
        reader = Reader.new("<root/>")
        reader.to_unsafe.should be_a(LibXML::XMLTextReader)
      end
    end
  end
end

This is effectively #8544 and has been fixed in #11636.

[straight-shoota]

Oh what a mess. What options do we have? I suppose we could skip either of those specs when building with an old compiler? 🤔
It would only be necessary when both are combined, but that might be hard to detect? We could look whether XML is defined in the atomic spec though...

[HertzDevil]

We could also simply replace the typedefs with aliases on versions before 1.3, or even without a version check

[straight-shoota]

Related discussion about dropping type entirely from the language: #10031

[ysbaddaden]

This exhibits the same issue as #14402: Pointer#address and Pointer#object_id are both UInt64, whatever the actual pointer size, so that will require a DWCAS on 32-bit archs :(

[straight-shoota]

@ysbaddaden I suppose there's no way around that until we introduce arch-specific pointer sizes. If you need to put a pointer into an atomic, you'll have to eat that. This PR doesn't really change anything about that because the current workaround would be to put Pointer#address in the atomic.

I suppose you could technically downcast the integer type on a arch with smaller pointer size, but unlikely anyone is going this extra length. Anyways, if you want, you can still do that after this PR. It just enables an easier use case without invalidating anything that worked before.

[HertzDevil]

Looking at this again, if sizeof(Void*) is target-specific but the type of Pointer#address isn't, then casting a smaller pointer to UInt64* is simply wrong and leads to stack corruption

[ysbaddaden]

Thanks @HertzDevil it looks perfect!

Shall we extract the libxml2 fix to have a distinct commit in master, or just squash it here?

[straight-shoota]

Shall we extract the libxml2 fix to have a distinct commit in master, or just squash it here?

I missed this comment. But it seems like a good idea, it's an unrelated change.
Let's wait for #14494 then.