[silgen] When performing existential erasure, be sure that we have a … #21099
Conversation
…plus one value. This both fixes the issue in SILGenPoly that exposed the problem and additionally introduces a check in asserts builds to ensure that we catch this problem in the future. rdar://43398898
|
@swift-ci smoke test |
| bool allowEmbeddedNSError) { | ||
| // Mark the needed conformances as used. | ||
| for (auto conformance : conformances) | ||
| SGM.useConformance(conformance); | ||
|
|
||
| // A wrapper around inputF that makes sure we are passed a +1 value if we are |
There was a problem hiding this comment.
This feels like a hack. Why not convert it to a +1 value where necessary when you actually call F?
There was a problem hiding this comment.
Actually isn't the +1-ness supposed to be encoded in the SGFContext? The original intent of the code was that everything produced a +1 value unless SGFContext.allowPlusZero() was true.
There was a problem hiding this comment.
@slavapestov I don't think it makes sense to do existential erasure on +0 value. You are producing a new value independent of the original value. That says it must be an owned value.
There was a problem hiding this comment.
I am converting it to the +1 when calling F in the caller. This is just the callee can assert that is true in a way that should optimize out in no-asserts build.
I am fine changing the code in the caller to check the SGFContext though instead of doing ensurePlusOne.
|
I fixed it the way you guys suggested (figuring out why we were not respecting the +1 context and making us obey said context): #23216. |
…plus one value.
This both fixes the issue in SILGenPoly that exposed the problem and
additionally introduces a check in asserts builds to ensure that we catch this
problem in the future.
rdar://43398898