OpaqueArchetypeSpecializer: inlinable functions are now in this module #27856
Conversation
Also fix a comment typo while I'm here.
...not the one they came from. This is important when specializing an inlinable function that takes an opaque type as a generic argument: that opaque type should still be considered opaque even if it came from the same module as the inlinable function. rdar://problem/56410009
No functionality change.
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
This fixes the issue but I need you reviewers to tell me whether it is the right fix. (Otherwise, please take the bug from me; I've done all I can do!) |
| dc = inFunction->getModule().getSwiftModule(); | ||
| auto *currentModule = inFunction->getModule().getSwiftModule(); | ||
| if (!dc || !dc->isChildContextOf(currentModule)) | ||
| dc = currentModule; |
There was a problem hiding this comment.
Would it not be correct to always use currentModule here? I think the SILFunction's dc is only meant for debugging.
There was a problem hiding this comment.
Yes, it would be correct. The intention of using the current functions current decl context is to be able to optimize the case when you have private declarations in the same sourc file.
Along the way of this micro optimization I introduced the bug that Jordan is fixing here :( .
|
Are we likely to have further issues where we use the DC of a SIL function? Should we consider not serializing that information? …no, wait, I guess we use it to identify things that came from Clang… |
|
The source compat failure is a single project failing to clone rather than something this commit changed, so I'm going to merge anyway. |
...not the one they came from. This is important when specializing an inlinable function that takes an opaque type as a generic argument: that opaque type should still be considered opaque even if it came from the same module as the inlinable function.
rdar://problem/56410009. Fixes a regression introduced in #27666.