There was some discussion about how to handle generated methods in stack traces in #11432, in particular I brought it up in this comment: https://github.com/golang/go/issues/11432#issuecomment-146269822. The discussion eventually led to the addition of the new runtime.CallersFrames API, but providing metadata about generated functions was considered orthogonal and left for possible followup work.
Chris On Monday, August 15, 2016 at 3:13:46 PM UTC-4, Ian Lance Taylor wrote: > > On Mon, Aug 15, 2016 at 10:51 AM, Tim Hockin <tho...@google.com > <javascript:>> wrote: > > OK, is there ANY heuristic I can rely on find the "real" call frame? > > I don't know. Sorry. As I said earlier, I don't have a good answer here. > > You should open an issue for this. For some reason it has not been a > problem, perhaps because most code doesn't use the wrapper methods > much. One reliable approach you could take would be to not call > runtime.Callers(1) from a value method or from a method in a type that > you embed into another type. But I understand that that is not a > satisfactory answer. > > Ian > > > > On Mon, Aug 15, 2016 at 10:17 AM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > >> On Sun, Aug 14, 2016 at 10:07 PM, Tim Hockin <tho...@google.com > <javascript:>> wrote: > >>> Can I rely on "<autogenerated>" not changing? > >> > >> I'm sorry, that's a hard question to answer, because other compilers > >> do not use that string. > >> > >> There are no plans to change that string for the gc toolchain. > >> > >> Ian > >> > >>> On Sun, Aug 14, 2016 at 9:55 PM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > >>>> On Sun, Aug 14, 2016 at 9:41 PM, Tim Hockin <tho...@google.com > <javascript:>> wrote: > >>>>> On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor <ia...@golang.org > <javascript:>> wrote: > >>>>>> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin <tho...@google.com > <javascript:>> wrote: > >>>>>>> Edit: It looks like this has more to do with being an interface > >>>>>>> method than an embedded type. > >>>>>>> > >>>>>>> https://play.golang.org/p/I5XPdWR_O0 > >>>>>> > >>>>>> Hmmm, you're right. It only happens for a value method. > >>>>> > >>>>> Is this likely to change? I.e. can I hardcode "2" or should I > actually > >>>>> write the loop to climb frames? Is there a limit to the number of > >>>>> frames I should inspect before I give up? Is the string > >>>>> "<autogenerated>" stable? > >>>> > >>>> Well, unfortunately, it's different for different compilers. I don't > >>>> have a good answer here. Except to say that you should never need > >>>> more than 2 frames; it should never be the case that autogenerated > >>>> code calls autogenerated code. > >>>> > >>>> Ian > -- 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.
