add unstable-core-ffi-objc feature

[jbatez]

For if/when feature(core_ffi_objc) is added to the nightly compiler.
rust-lang/rust@master...jbatez:rust:rustc_objc_class

[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.