Replace objc with objc2

[madsmtm]

Redo of #513, see that for previous discussion and motivation (GitHub Actions was giving me trouble).

---

I've focused on making this PR as minimal as possible, that is, I'm explicitly not trying to actually use any of the new features that objc2 offers - we can discuss those separately as we get there. So as-is, this PR is only a small improvement on the status quo, though still definitely an improvement.

The main difference you have to know for now is that all arguments and return types must implement a specific marker trait objc2::encode::Encode, which makes it possible to catch type mistakes at runtime, when debug assertions are enabled (e.g. cases of passing an u32 where an isize was expected). This is a huge boon to soundness, and the few mistakes I've found and corrected are likely only the tip of the iceberg - I could use someone's help to run this on bigger code-bases that exercise more of cocoa/cocoa-foundation.

Feel free to ask any questions about anything!

CC recent contributors @jrmuizel, @mukilan, @jdm and @michaelwright235.

[madsmtm]

(That the semver checks are failing is expected, this is a breaking change).

[nicoburns]

@madsmtm Do you have a read on how this crate differs from the relevant higher-level crates in the objc2 family? (are there equivalent crate(s)). Would it make sense to look at more heavily adopting some of those crates? Or even outright replacing (some of?) the crates in this repo with ones from https://github.com/madsmtm/objc2 ?

[madsmtm]

Do you have a read on how this crate differs from the relevant higher-level crates in the objc2 family? (are there equivalent crate(s)). Would it make sense to look at more heavily adopting some of those crates? Or even outright replacing (some of?) the crates in this repo with ones from https://github.com/madsmtm/objc2 ?

There's some fairly old discussion of a few lower-level details in #513, but yeah, nowadays we have objc2-foundation, objc2-app-kit and objc2-quartz-core, which completely replace the functionality in cocoa, along with providing:

• Actual type safety (everything isn't just an id pointer)
• Proper memory management (no longer need to do retain/release calls, autorelease pools aren't as important)
• Automatically generated bindings to almost everything in those frameworks

[nicoburns]

A couple of followup questions:

• Does this extra type safety and generated bindings have compile time and/or code size implications?

• Are there bindings for CoreText somewhere in the objc2 family of crates? Those seem to be a heavily used part of this repo, but I couldn't find them for objc2. And if not, are there other frameworks for which bindings are currently missing?

[madsmtm]

Does this extra type safety and generated bindings have compile time and/or code size implications?

They do have a compile-time cost, but it's quite low by now if you only enable the features you need, see the docs.

Wrt. code-size, as long as you use LTO, there shouldn't be a difference. I'm considering adding #[inline] to ensure that this happens without, but I'm slightly unsure of the compile-time cost of doing so, so haven't done it yet.

Are there bindings for CoreText somewhere in the objc2 family of crates? Those seem to be a heavily used part of this repo, but I couldn't find them for objc2. And if not, are there other frameworks for which bindings are currently missing?

CoreText is in the category of a CoreFoundation-like framework, these aren't supported yet because they don't actually use Objective-C, and the memory management scheme is completely different, see madsmtm/objc2#556.

[waywardmonkeys]

I think it is worth extracting at least 2 parts of this out (the changes to core-text and core-graphics-types) and considering them separately from the changes to cocoa and cocoa-foundation.

[waywardmonkeys]

I think there's value in having a standalone PR that adds the Encode traits for objc2 to core-graphics-types via a feature. Would that help for some of what you maintain in the objc2 family of crates?

It is separate from converting the cocoa and cocoa-foundation crates, right?

[madsmtm]

Hmm, I think it would help, though I'll have to mull it over; it kinda depends on how long it will take me to get to doing madsmtm/objc2#556 (in which case all the types in this repo will just be autogenerated), and I suspect a lot of people would be annoyed at the extra dependency.

[madsmtm]

I think it is worth extracting at least 2 parts of this out (the changes to core-text and core-graphics-types) and considering them separately from the changes to cocoa and cocoa-foundation.

Gotta admit, I'm not really motivated to work on this repo rn (though I may become so in the future, esp. considering you just joined as maintainer).

In any case, I've extracted the first commit into #702, as I indeed think that change is valuable on its own, and does make things easier to review here.

[wusyong]

@madsmtm I think it's okay to wait. Perhaps Servo should use objc2's framework bindings, just as Servo recently migrated from winapi to windows-sys.
Though several frameworks Servo uses don't exist yet, we could discuss this in future issues.