[swift-dev] No return functions and program exit

[Joe Groff]

> On Feb 6, 2017, at 11:04 AM, Michael Gottesman <mgottesman at apple.com> wrote:
> 
>> 
>> On Feb 6, 2017, at 10:04 AM, Joe Groff <jgroff at apple.com> wrote:
>> 
>> 
>>> On Feb 6, 2017, at 9:48 AM, Michael Gottesman via swift-dev <swift-dev at swift.org> wrote:
>>> 
>>> One thing that is an issue that has come up with ownership is that at the SIL level we do not distinguish in between exceptional noreturn functions and exceptional return functions.
>>> 
>>> This is important since in the non-exceptional case, we would like to clean up all of the values used in the current function before calling the no-return function. An example of such a function is dispatch_main from libdispatch. In the exceptional case though, we are ok with leaking since the program will be exiting. Beyond reducing code size (I guess?), the argument I have heard for this is that this will allow for people to examine values in the debugger since we will not have cleaned things up before the abort is called.
>>> 
>>> From what I can tell, if we are going to distinguish in between these cases, then we need a distinction in between the two baked into the compiler. Thoughts? I have code written that will enable either case to be handled as long as I can distinguish in between them at the SIL level.
>> 
>> The interesting distinction here to me strikes me as being the temporal rather than exceptional nature of the exit. _exit(2) isn't an "exceptional" noreturn per se, but you'd still want to leak cleanups before it since the program's termination comes immediately after the call. If it's a profitable distinction to be made, I think there are few enough immediate-exit primitives like exit, abort, fatalError, etc. that we could probably whitelist them with a @_semantics attribute for now, and maybe use an early SIL pass to propagate the attribute in obvious cases where a function is a simple wrapper around one of those functions.
> 
> I am fine with either approach as long as we make a decision.
> 
> But just to bring it up in the discussion, Alexis brought up in chat an interesting point, namely what about higher level functions? I guess we don't care about that case?

For higher-order functions, I think we should optimize for the common case that their generic parameters are inhabited. Like Jordan said, micromanaging the policy here is already tottering on the edge of diminishing returns for first-order noreturns; trying to accommodate every possibility of injecting an uninhabited type somewhere definitely feels like overkill.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-dev/attachments/20170206/74c40e74/attachment.html>