Skip to content

[ABI] [Mangling] Disambiguate protocol-conformance-ref better #21448

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 1 commit into from

Conversation

jrose-apple
Copy link
Contributor

@jrose-apple jrose-apple commented Dec 20, 2018

Fix to #21397. The mangling operator "HP" has to distinguish between "protocol" and "protocol + module", not between the presence or absence of protocol-conformance-ref. New grammar:

protocol-conformance-ref ::= protocol
protocol-conformance-ref ::= protocol module 'HP'

rdar://problem/46735592, again. This is a narrow fix for that issue; the problem only occurs when mangling a reference to a non-retroactive conformance, but it's happening in a context where we only need retroactive conformances anyway. I'll look into that next and if it's simple enough maybe we can take that too.

Fix to 510b64f. The mangling operator "HP" has to distinguish
between "protocol" and "protocol module", not between the presence
or absence of protocol-conformance-ref. New grammar:

    protocol-conformance-ref ::= protocol
    protocol-conformance-ref ::= protocol module 'HP'

rdar://problem/46735592, again
@jrose-apple
Copy link
Contributor Author

@swift-ci Please test

@jrose-apple
Copy link
Contributor Author

@swift-ci Please test source compatibility

Copy link
Contributor

@rjmccall rjmccall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is definitely a better mangling.

So something trying to identify what module a conformance belongs to would need to figure out what the module dependency relationship is between the type and the protocol, right? If we wanted to find a conformance dynamically, we'd probably have to check in both places. Seems a little unfortunate.

@jrose-apple
Copy link
Contributor Author

That's true. If we think that's important to encode, we could always include the module name if it's different from the type xor the protocol, or use a different operator, or use a dummy module name to indicate "same as type" xor "same as protocol" (with the absence of any module name indicating the other).

@rjmccall
Copy link
Contributor

I think you mean "either the type or the protocol", right? I think I'd be happier with a couple of operators for each of those two cases, yeah, so that it would be:

  protocol-conformance-ref ::= protocol '??'       // conformance from protocol's module
  protocol-conformance-ref ::= protocol '??'       // conformance from type's module
  protocol-conformance-ref ::= protocol module 'HP'    // retroactive conformance

...although all of the manglings here are pretty weird and worrisome, so maybe I should just put my head back in the sand.

@jrose-apple
Copy link
Contributor Author

Continuing in #21450, since @DougGregor approved the secondary change there.

@jrose-apple jrose-apple deleted the shark-tank branch December 20, 2018 22:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants