Add a new attribute, "?", to the property attribute string for properties of protocols that are declared @optional.
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
This LGTM for apple's runtime assuming it knows how to handle the new string.
clang/lib/AST/ASTContext.cpp | ||
---|---|---|
7857 | You can omit braces here. | |
clang/test/CodeGenObjC/objc-asm-attribute-test.m | ||
20 | Do you need this change? | |
72 | Can you use regular expression for the two globals above and check they are referenced in @"_OBJC_$_PROP_LIST_MySecretNamespace.Protocol2? |
clang/test/CodeGenObjC/objc-asm-attribute-test.m | ||
---|---|---|
20 | No, I think this is left-over from an earlier revision. I'll get rid of it. |
@theraven Any chance you could glance over this and reassure us that it isn't going to break the GNU runtime if we do this? (We're adding an extra attribute in the property attribute string so that we can detect @optional properties in ObjC protocols at runtime.)
It shouldn't, we ignore any unknown property attributes. I'd be more concerned about code outside the runtime. Lots of things parse encoding strings badly, but the property APIs make it much easier to query known attributes and so I think that's a lot lower risk than changing anything in encoding strings. It's a shame to use ?, since that is unknown type in type encodings and that may confuse some parsers..
I don't think using ? is really an issue here; anyone parsing types from these strings already has to stop for the , character, since the string is defined to be a ,-separated list of attributes, the first of which is the type attribute T<type encoding>. If they were going to be confused by the ?, then they'd already get confused by the other attribute characters, many of which are also valid in a type encoding.
Do you need this change?