> On Feb 6, 2017, at 9:48 AM, Michael Gottesman via swift-dev > <swift-dev@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. -Joe _______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
