Skip to content

Protocol resilience preliminaries #15443

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

Merged

Conversation

slavapestov
Copy link
Contributor

Landing a few small patches first for better testing and review.

@slavapestov slavapestov requested a review from rjmccall March 23, 2018 03:56
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@@ -1901,6 +1901,9 @@ struct TargetProtocolRequirement {
ProtocolRequirementFlags Flags;
// TODO: name, type

/// Dispatch thunk. Will be null if the protocol is not resilient.
RelativeDirectPointer<void, /*nullable*/ true> Function;
Copy link
Contributor

Choose a reason for hiding this comment

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

I think this comment, and probably the field name, could be a lot clearer. I'll admit that I went down a garden path because of the word "dispatch" in the comment, but still, some sort of statement about what the function does would be good. It only clicked for me when I read the rest of your patch.

You should include some level of explanation of why this needs to be linked here. Currently that's just in the commit message.

Is it really a good idea to base this keying off of function-pointer equality? I'll admit to feeling a bit burnt from C++ inline functions, and some of those reasons don't apply here, but... function pointers are very opaque, and there are sometimes good reasons to introduce thunks around them. On the other hand, it is a symbol that's guaranteed to be exported.

StructLayoutFlags flags,
size_t numFields,
const TypeLayout * const *fieldTypes,
size_t *fieldOffsets);
Copy link
Contributor

Choose a reason for hiding this comment

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

Please typedef StructLayoutFlags to ClassLayoutFlags.

@@ -216,6 +216,7 @@ IRGenModule::IRGenModule(IRGenerator &irgen,

ProtocolRequirementStructTy =
createStructType(*this, "swift.protocol_requirement", {
Int32Ty, // thunk
Copy link
Contributor

Choose a reason for hiding this comment

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

Comments are out of order here.

@slavapestov slavapestov force-pushed the protocol-resilience-preliminaries branch 2 times, most recently from b79dd5c to 94f8267 Compare March 23, 2018 07:59
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov slavapestov force-pushed the protocol-resilience-preliminaries branch from 94f8267 to c7d7c92 Compare March 23, 2018 22:49
Rename it to swift_initClassMetadata() just like we recently did
swift_initStructMetadata(), and add a StructLayoutFlags parameter
so we can version calls to this function in the future.

Maybe at some point this will become a separate ClassLayoutFlags
type, but at this point it doesn't matter because IRGen always
passes a value of 0.
Tests fail with the next patch.
These will be used as lookup keys for order-independent witness
table instantiation. In the future, a reflective call mechanism
could make use of this metadata as well.
@slavapestov slavapestov force-pushed the protocol-resilience-preliminaries branch from 787b117 to 982a50a Compare March 24, 2018 00:59
@slavapestov
Copy link
Contributor Author

@swift-ci Please smoke test

@slavapestov slavapestov merged commit efa619a into swiftlang:master Mar 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