Skip to content

[WIP] Use symbolic references more liberally. #19903

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

jckarter
Copy link
Contributor

@jckarter jckarter commented Oct 16, 2018

Introduce symbolic references for indirect references to type context descriptors in other object files, and a new kind for references to protocol conformance descriptors (which will be used to mangle general generic arguments for key paths)

TODO:

  • Update IRGen tests for changed output
  • Fix an issue with reflection of symbolic-referenced protocol contexts (evident in failing test/Reflection tests)

Deferred:

  • Handle indirect symbolic references correctly in Reflection tests. This probably means that the Mach-O/ELF/COFF ObjectMemoryReaders need to learn to resolve relocations among multiple disk files, alas. For now, I've kept symbolic references across files disabled.

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

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

This looks very promising!

if (auto ty = referent.dyn_cast<const NominalTypeDecl*>())
appendContext(ty);
else if (auto proto = referent.dyn_cast<const ProtocolDecl*>())
appendContext(proto);
Copy link
Member

Choose a reason for hiding this comment

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

Given that a ProtocolDecl is-a NominalTypeDecl, we have to be excessively careful with that referent type. Do we need the protocol vs. nominal type distinction here?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Probably not. I started out giving type and protocols different symbolic reference discriminators, but that ended up being unnecessary.

@@ -662,3 +662,247 @@ bool LinkEntity::isAvailableExternally(IRGenModule &IGM) const {
}
llvm_unreachable("bad link entity kind");
}

llvm::Type *LinkEntity::getDefaultDeclarationType(IRGenModule &IGM) const {
Copy link
Member

Choose a reason for hiding this comment

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

This is a very nice and mostly unrelated cleanup ;)

LinkEntity::forProtocolConformanceDescriptor(conf->getRootNormalConformance()));

// \3 - direct reference, \4 - indirect reference
baseKind = 5;
Copy link
Member

Choose a reason for hiding this comment

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

Shouldn't this be 3 instead of 5?

if (auto retroContext = conformance->getRetroactiveContext()) {
module = retroContext->getModuleContext();
} else {
// FIXME: Assume the protocol's module for a non-retroactive conformance
Copy link
Member

Choose a reason for hiding this comment

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

Non-retroactive conformances could be either in the protocol's module or the conforming type's module. If we need it, we could add a bit to the conformance descriptor to say which one it is...

(const ContextDescriptor *) context,
{}, Dem);
});
Demangle::mangleNode(node, ExpandResolvedSymbolicReferences(Dem));
Copy link
Member

Choose a reason for hiding this comment

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

Thanks for cleaning up the DRY violations here

~~~~~~~~~~~~~~~~~~~

The Swift compiler emits mangled names into binary images to encode
references to types for runtime instantiation and reflection.Within an
Copy link
Member

Choose a reason for hiding this comment

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

Missing space after "reflection."

@DougGregor
Copy link
Member

Indirect symbolic references will let us re-land #19848

@jckarter jckarter force-pushed the more-symbolic-references branch 2 times, most recently from 1cb1873 to 388ddfe Compare October 19, 2018 23:29
@DougGregor
Copy link
Member

Note that this is obsoleted by #20005, so I'm going to go ahead and close it.

@DougGregor DougGregor closed this Oct 24, 2018
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.

2 participants