This is an archive of the discontinued LLVM Phabricator instance.

AST: support ObjC lifetime qualifiers in MS ABI
ClosedPublic

Authored by compnerd on Jan 27 2018, 10:29 AM.

Details

Reviewers
rjmccall
Summary

Adjust the ObjC protocol conformance workaround to be more extensible.
Use a synthetic type for the protocol (struct Protocol). Embed this
within a reserved namespace to permit extending the extended pointer
type qualifiers similarly for ObjC lifetime qualifiers.

Introduce additional special handling for __autoreleasing, __strong,
and __weak Objective C lifetime qualifiers. We decorate these by
creating an artificial template type Autoreleasing, Strong, or
Weak in the __ObjC namespace. These are only considered in the
template type specialization and not the function parameter.

Diff Detail

Repository
rC Clang

Event Timeline

compnerd created this revision.Jan 27 2018, 10:29 AM

pin_ptr is technically not supposed to appear as a function parameter, and having it in that position can screw up demangling. Considering __strong is the default, it's probably not a good idea to map that one to pin_ptr; whichever qualifier is least likely to appear as a function parameter (though I don't know which one that is) should map to pin_ptr. The other lifetimes seem to demangle fine wherever you place them.

Do you want to add some tests for the mangling of qualifiers on function parameters themselves? That would also demonstrate the potential demangling issue.

It's not just that functions can't be overloaded on the parameter-variable type qualifier — it's not part of the function type at all, just like making a parameter 'const int' instead of 'int' is not part of the function type. I understand that MSVC mangles some things that really shouldn't be mangled, but I would greatly prefer if you could make an exception for this.

Separately, re-using existing manglings like this seems *really* sketchy. Is this 100% necessary? There's no way to just fake something up?

Hmm, the only thing that we could fake would be namespaces on the parameter types. Is that better? I'm not tied to re-using the existing mangling.

Hmm, the only thing that we could fake would be namespaces on the parameter types. Is that better? I'm not tied to re-using the existing mangling.

I'm just worried about re-using the existing mangling causing a problem in the long run. If you're certain that it would never be sensical to talk about e.g. a cli::pin_ptr<__strong id>, then ok.

Yeah, Im afraid I cannot definitely say that will never be sensible. I think I would, in fact, prefer an alternative. I'm just not sure what is a good viable alternative, especially since we are constrained in what the grammar accepts. The desugaring of the id and Class types is the saving grace here that grants us some ability to tweak the mangling.

compnerd updated this revision to Diff 133319.Feb 7 2018, 3:07 PM
compnerd edited the summary of this revision. (Show Details)

Address comments from @rjmccall

@rjmccall, I've updated the approach and no longer abuse the existing decoration styles. This uses a custom namespace with artificial types to differentiate the types. I've also ensured that the parameter types do not encode the type information.

rjmccall accepted this revision.Feb 7 2018, 10:41 PM

@rjmccall, I've updated the approach and no longer abuse the existing decoration styles. This uses a custom namespace with artificial types to differentiate the types. I've also ensured that the parameter types do not encode the type information.

Alright, thanks, LGTM.

This revision is now accepted and ready to land.Feb 7 2018, 10:41 PM
compnerd closed this revision.Feb 10 2018, 10:31 AM

SVN r324701

test/CodeGenObjCXX/msabi-objc-extensions.mm