add unstable-core-darwin-objc feature

[jbatez]

Uses the darwin_objc (rust-lang/rust#145496) language feature.

[madsmtm]

Thanks! I'm probably going to wait with merging this until there's at least a rust-lang/rust PR open that we can point people towards.

[jbatez]

I added support for the class! macro as well but just realized extern_class! uses __class_inner! directly. Since extern_class! needs to support #[name = "StringLiteral"], that complicates my core::ffi::objc::class! macro which expects an identifier and not a string literal.

I wonder if my core::ffi::objc macros should just take string literals.

[jbatez]

I made core::ffi::objc::class! accept either an identifier or a string literal and got it working with extern_class!.

[madsmtm]

Re identifier vs. string literal: I tend to think the core::ffi::objc::* macros might actually want to only accept string literals for simplicity? Because to the runtime, that is what they are, it is only incidental that Objective-C prevents you from having weird things in them like spaces.

They aren't even limited to UTF-8, so might actually make sense to force c-string literals, to prevent interior NUL bytes by construction?

[jbatez]

I'd be ok with string literals only. C-string literals only would make extern_class! #[name = "StringLiteral"] difficult, though, right? I don't know how I'd do that without procedural macros.

[jbatez]

#[export_name = ""] and #[link_name = ""] have similar design constraints, fwiw. They disallow interior NUL bytes and I imagine there are platforms out there that support non-Unicode symbols that Rust has no way of handling.

EDIT: Only export_name disallows nulls, but I think the point still stands.

[madsmtm]

Both good points, then a normal string literal is probably fine.

[jbatez]

Done. They now expect string literals and are used in new implementations of __class_inner! and __sel_inner!. Since core::ffi::objc::selector! doesn't expect a null-terminator, I added a new __sel_data_terminate! macro that conditionally null-terminates. It's used in __sel_data! and in common_selectors.rs.

Though now I'm wondering if I should change __sel_inner to never expect null-terminated data and instead have it decide whether or not to add a null-terminator.

[jbatez]

The rustc feature plan has changed slightly. See rust-lang/rust#145496. I'll revisit this PR once we make more progress on the rustc changes.

[jbatez]

Updated now that darwin_objc is in nightly.

I tested with examples/metal and am about to add it as an optional feature to the other examples.

[jbatez]

@madsmtm is there anything else you'd like to see before this gets merged?

[madsmtm]

Only have a few smaller things, am otherwise happy with this as-is.

If you don't get to it within the next few days, I'll probably fix it myself, I'd like to get the framework crate parts out with v0.3.2.

[madsmtm]

Nit: The examples actually can use:

Suggested change

	unstable-core-darwin-objc = []
	unstable-core-darwin-objc = ["objc2/unstable-core-darwin-objc", "objc2-foundation/unstable-core-darwin-objc"]

Because we don't ship them anywhere.

[jbatez]

I left them out because running cargo run --example <name here> --features unstable-core-darwin-objc seemed to enable it in all the dependencies implicitly. I'm no cargo expert, though, so I defer to you on this.

[madsmtm]

Yeah, but it doesn't happen if you do cargo run -pexamples-audio --example speech_synthesis --features unstable-core-darwin-objc (or you are cd-ed into examples/audio). I went and added it.

[madsmtm]

Nit: I'd prefer this was named something more descriptive, maybe unstable-static-via-rustc, unstable-static-nightly or unstable-static-proper? At the very least, it should have static in the name.

[madsmtm]

Alternatively, we make it so that unstable-core-darwin-objc augments unstable-static-sel/unstable-static-class (so you need to enable all three).

[jbatez]

I prefer the augmentation approach since in most of the crates all this feature does is enable the darwin_objc language feature. Maybe unstable-rustc-darwin-objc is a better name?

I'm a little busy this weekend so feel free to take over if you want it sooner.

[madsmtm]

I renamed it to just unstable-darwin-objc (since that is the name of the feature in the compiler), and went with the augmentation route.

[madsmtm]

I went and implemented the things I suggested myself, thanks again for your work here!

[jbatez]

No problem, thanks for all your help!