[silgen] When emitting a top level error, destroy the error after we … #20033
Conversation
|
@swift-ci smoke test |
|
Can we put the destroy after the call to |
|
@jrose-apple the destroy is after the call to errorInMain... This is an error path so I am not sure if it is worth optimizing out the destroy. That being said, I could use an end_lifetime and we could just leak it using that. |
|
Oops, not sure how I misread that! Okay, so we're not paying the run time cost…but we might still be paying in code size. |
|
Ok. I can make that change. I don't think the code-size impact is large... but why not save some if we can. |
…r we have logged it. This is not strictly necessary since we are going to be exiting the program, but the ownership verifier thinks that the error is leaked otherwise. By using the end_lifetime we avoid having a small increase in code-size since it is a no-op after ownership is removed. rdar://29791263
gottesmm
force-pushed
the
pr-aef61f8fa8d192698e4fe42ceef1bc68d72337e8
branch
from
5996adf to
88979f9
Compare
|
@swift-ci smoke test and merge |
4 similar comments
|
@swift-ci smoke test and merge |
|
@swift-ci smoke test and merge |
|
@swift-ci smoke test and merge |
|
@swift-ci smoke test and merge |
|
@swift-ci smoke test os x platform |
1 similar comment
|
@swift-ci smoke test os x platform |
|
@jckarter That feels like a larger design question to me. I think the simplest way that one could do that is to have a privileged return value. But I think we would need to discuss that and I am not sure if that should hold up this PR. |
|
I talked with @jckarter offline. He is ok with my merging this and filing an SR with his enhancement proposal. It is here: https://bugs.swift.org/browse/SR-9114. |
…have logged it.
This is not strictly necessary since we are going to be exiting the program, but
the ownership verifier thinks that the error is leaked otherwise.
rdar://29791263