To avoid breaking changes in the future it should definitely be a list of maps. But yes, please open up an issue. We can have it as Mix.Tasks.Xref.calls/0.

The issue is the API guarantees. For example, last week we changed runtime_dispatches and compile_dispatches to also include the file in some cases and that would have broken any code that relied on those functions to return only lines, as it did before. It has more information now but the change could be considered a breaking one.

The other downside of relying on runtime_dispatches and compile_dispatches is that then it is a tool specific to Mix? Could I for example have a foo.exs file that would just work with that?

Yes, that’s enough, but I’d prefer a normal Elixir function instead of a command that forced me to parse text. For each function, I need something like:

{{module, function, arity}, caller_module, file, line}

Or possibly a map instead of a tuple. The caller_module might be optional, I have to see if I can derive it from the line number alone.

Maybe I should file an issue asking for the minimum amount of information I can’t derive any other way?

I was thinking about adding the following features.

I’d like to have a special page which shows, for each function all functions that call it. I would like to have something in which when you click a function definition you’d be taken to the corresponding page where you could see all places where the function is called. This would be very useful to get a sense of how the function fits in the whole.

For example, if you have this definitions:

def my_func(x, y), do: ...

when you clicked the my_func name you would be redirected to a page where you can find all functions and modules that call my_func. This is pretty much trivial to implement (I have a function call database that makes it easy), I just have
to make time for it.

I would like to have a function call graph or dependency graph somewhere. I can either embed a static image of the graph, but that’s not very useful. An interactive graph would be better. There are GraphViz implementations in Javascript, so this can be doable.

Pinging @josevalim because of an old discussion (here: Access to some information not available in mix xref) regarding opening up parts of the Mix.Xref for external use. Currently, Guaxinim requires access to the runtime_dispatches and compile_dispatches to find the function calls in the source. I assume similar projects might be interested in this information too.

Making these fields accessible (properly encapsulated, of course) doesn’t seem o constrain Mix.Xref a lot.

Also, some parts of Guaxinim could be included in Mix.Xref. Currently, Mix.Xref doesn’t find intra-module function calls, which is very easy to do with access to the BEAM debug chunks.