OK, is there ANY heuristic I can rely on find the "real" call frame?
On Mon, Aug 15, 2016 at 10:17 AM, Ian Lance Taylor <i...@golang.org> wrote: > On Sun, Aug 14, 2016 at 10:07 PM, Tim Hockin <thoc...@google.com> 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 <i...@golang.org> wrote: >>> On Sun, Aug 14, 2016 at 9:41 PM, Tim Hockin <thoc...@google.com> wrote: >>>> On Sun, Aug 14, 2016 at 8:31 PM, Ian Lance Taylor <i...@golang.org> wrote: >>>>> On Sun, Aug 14, 2016 at 3:33 PM, Tim Hockin <thoc...@google.com> 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.