One thing to know about Go's escape analysis is that it works bottom up, package by package, so it does use interprocedural information. Right now that information is pretty coarse, on the level of "escapes", "content escapes", and "[content] transmitted to result N".
For a parameter with interface type, one way of augmenting that might be to not automatically give up upon seeing an invokeinterface, but instead to list the interface methods applied to the value (e.g., "String()"). This is also a problem where there is no dishonor in taking hacky shortcuts, so we might only record PARAM.method(...) instances, and still punt for P2 given an expression like P1.method(P2). On Sunday, October 2, 2016 at 4:57:43 AM UTC-4, Aliaksandr Valialkin wrote: > > fmt.* functions may call Stringer and Formatter interface methods for the > passed arguments, so the arguments may escape when calling these methods. > > Probably, conditional escaping may be implemented for function argument. > For example of fmt.*, escape only arguments implementing Stringer or > Formatter interfaces when passing them to fmt.Println. Furthemore, such > arguments may be left on stack if the corresponding Stringer and Formatter > methods don't escape the argument. > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
