[SR-589] Plumbing for dynamic instantiation of generic types #959
Conversation
lhoward
force-pushed
the
SR-381-generic
branch
30 times, most recently
from
e60cde2 to
2c951d9
Compare
lhoward
force-pushed
the
SR-381-generic
branch
3 times, most recently
from
19417b8 to
2e51637
Compare
lhoward
changed the title
lhoward
changed the title
|
Thanks for the heads up @slavapestov, won’t be able to take a look until next week but I will do then. |
lhoward
force-pushed
the
SR-381-generic
branch
from
2e51637 to
aa4664f
Compare
|
Rebased and tests passing.
|
This extends
<swiftlang@b5880f3>
with the infrastructure necessary to dynamically instantiate generic types by
name. In order to do so it extends GenericParameterDescriptor::Parameter with a
list of ProtocolDescriptors containing associated type requirements.
NB: no support for secondary archetypes yet.
NB: this is "plumbing" as we have not defined a Swift API yet to lookup
anything beyond a top-level non-generic class. The test suite uses private API
taking a mangled type name in order to exercise this new code.
lhoward
force-pushed
the
SR-381-generic
branch
from
aa4664f to
e6a154d
Compare
|
@swift-ci please test |
| auto targetAddr = llvm::ConstantExpr::getPtrToInt(target.first, IGM.SizeTy); | ||
| auto offset = llvm::ConstantInt::get(IGM.SizeTy, getNextOffset().getValue()); | ||
| // This seems incredibly baroque, we should be creating an LLVM struct? | ||
| // not sure how to define one with nested tail-emplaced values |
There was a problem hiding this comment.
Would an anonymous LLVM struct type work?
|
Because there hasn't been action on this in quite some time, I'm going to close this pull request. @lhoward thank you for your work here. Please reopen this if you wish to continue it. |
|
With the new remote reflection stuff that went in, the correct way to implement this functionality is now to write a library function for constructing Metadata from a TypeRef. Then we can also use this to replace the field type vectors in IRGen. Unless @lhoward wants to take this on, I'll be working on it some time in the coming year. |
|
@slavapestov – I’ve not yet looked at the remote reflection stuff, but is this something the metadata lookup path for non-generic types (swift_getTypeByMangledName) should also be using? |
|
@lhoward Yes - the goal with the remote reflection stuff is to have one general mechanism for turning a mangled type string into a type. This should allow it to work for mangled function and tuple types, and so on, in full generality. |
|
Looks cool, I suspect you might get to it before I, but count me interested.
|
Clean up IRGen.cpp diff with upstream
This extends b5880f3 with the infrastructure necessary to dynamically instantiate generic types by name. In order to do so it extends GenericParameterDescriptor::Parameter with a list of ProtocolDescriptors for primary associated type requirements.
Some notes: