Using `reflect.FuncOf` leads to a provide log without much context

uber-go / fx

A dependency injection based application framework for Go.

https://uber-go.github.io/fx/

MIT License

5.65k stars 287 forks source link

Using `reflect.FuncOf` leads to a provide log without much context #604

Open prashantv opened 6 years ago

prashantv commented 6 years ago

If we have helper functions that return fx.Options, it's not possible to skip callers for logging, so we can end up with something like:

  fxtest.go:43: [Fx] PROVIDE  tchannelfx.Configuration <= reflect.makeFuncStub()

Ideally, we could customize the caller skip so we're showing something more instead of the helper functions.

prashantv commented 6 years ago

While discussing this with @abhinav, one idea I had was to use an optional struct tag to tell fx what to log.

E.g., if we had a helper that provides a type Channel, it shouldn't just fx.Provide(&Channel{..}), but instead can provide an annotated version of the type which contains an extra tag,

struct {
  fx.Out

  Ch Channel `debuginfo:"chfx.Helper(..)"`
}

When fx is printing debug information for a type, it can check for this extra tag and use that in place of the function name.

prashantv commented 4 years ago

This is coming up in #697 as well, so I think this is something we should prioritize.

Some more ideas: re: https://github.com/uber-go/fx/pull/697

Caller skip (similar to zap), to indicate the number of caller frames to skip in the log.
t.Helper style or something similar where the helper marks itself as a helper, and we find the first call frame before that helper call (we might need some sort of fx.Helper(func(...) {}) to easily identify the helper
Just pass in a stack directly as field in fx.Annotated or similar to use instead of figuring it out ourselves. This is similar to the above, but we should try and capture the whole stack.