Create closure destructors with internal linkage #86013
Conversation
This makes these symbols visible in backtraces, at the cost of binary size. The long-term goal is to generate these functions with LinkOnceODRLinkage, using the contents of the HeapLayout to produce a mangled name, so they can be deduplicated across modules. rdar://149084103
|
@swift-ci smoke test |
|
We should do the same for partial apply forwarders too. Today they're generated once per |
Does that mean we should change those to have internal linkage in the short term as well? This PR is just meant as a short-term fix for rdar://149084103. I will be away until after Christmas. |
|
@swift-ci test windows |
I think this comment is about the long term plan to deduplicate these functions. |
aidan-hall
left a comment
aidan-hall
left a comment
There was a problem hiding this comment.
I think the generated closure destructors could conflict with @c/@cDecl declarations in user code that use the name objectdestroy. Perhaps rename to __objectdestroy?
Can you explain what you mean? With internal linkage they should get properly uniqued. edit: Oh, I see... when people import C declarations. Yeah, maybe we can introduce some proper mangling here already, or just rename is also fine I guess. |
3 participants
This makes these symbols visible in backtraces, at the cost of binary size (partially reverts 5e9e68c).
The long-term goal is to generate these functions with LinkOnceODRLinkage, using the contents of the HeapLayout to produce a mangled name, so they can be deduplicated across modules.
rdar://149084103