Imagine that we have these two cases: 1. A function `f` with one anonymous function inside 2. A type `f` with method `func1` (f is a by-value receiver)
This will result in both entries to be identical in the generated profile. > pkg.f.func1 -- refers to anonymous function (1) > pkg.f.func1 -- refers to func1 method inside f This ambiguity can be solved with a types table, but that's too much of the effort in my opinion. For pointer receivers, we get a nice `pkg.(*f).func1` notation that can be parsed easily. We could use `pkg.(f).func1` to make value receiver methods distinguishable too. As far as I know, the whole point of this notation is to make symbols unique. This works, since we can't have `f` as a type name and a function name at the same time. Unfortunately, the current notation is not good enough to make these two distinguishable if we haven't parsed/typechecked package yet. This is not always possible and desirable: a profile should be useful even without the being sources available. Question: am I missing something? Is there an easy way to tell what profile symbol points to? I'm using https://github.com/google/pprof to parse the profiles. Thank you in advance! :) -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/fabad9e4-1790-415e-8915-08ed615bf31en%40googlegroups.com.
