Here is my suggestion: 1. We assume by default the leaking case. 2. We change noreturn functions from C to maybe have a special semantic tag on them that says that cleanups should occur before them (i.e. UIApplicationMain).
How does that sound? Michael > On Feb 6, 2017, at 11:08 AM, Joe Groff <jgr...@apple.com> wrote: > >> >> On Feb 6, 2017, at 11:04 AM, Michael Gottesman <mgottes...@apple.com >> <mailto:mgottes...@apple.com>> wrote: >> >>> >>> On Feb 6, 2017, at 10:04 AM, Joe Groff <jgr...@apple.com >>> <mailto:jgr...@apple.com>> wrote: >>> >>> >>>> On Feb 6, 2017, at 9:48 AM, Michael Gottesman via swift-dev >>>> <swift-dev@swift.org <mailto: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. >> >> 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
_______________________________________________ swift-dev mailing list swift-dev@swift.org https://lists.swift.org/mailman/listinfo/swift-dev
