You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.
I have read the Clojure etiquette and will respect it when communicating on this platform.
Is your feature request related to a problem? Please describe.
I would like to use the :var-usages data from the :analysis to perform static analysis.
Currently, it appears that no information about referenced vars is preserved for defmethod expressions and while referenced vars are preserved for defmulti expressions, the fact that the source var is a multimethod is not.
As a concrete example, assuming that I have the following namespace
From this we can see that foo is called from var bar (entry 2) and that identity is called from the var bar (entry 4).
Note that in entry 4 baz is not marked as a multimethod. The fact that the identity function is (part of) the dispatch-fn for the multimethod is not captured. Moreover, it is not shown that foo is also called from the multimethod baz with dispatch-val :call-foo.
Entry 6 suggests that baz is called from the top level (there is no :from-var).
Ideally, multimethods could be handled in a more nuanced way for the var-usage analysis.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I would like entry 4 in the :var-usages to include the key/val pair :defmulti true To indicate that identitymust have been referenced from the dispatch-fn. (I don't think there would be another reason to reference a var here?)
{:name identity, :from my-ns, :from-var bar, :to clojure.core :defmultitrue}
Entry 6 is slightly more problematic. Currently it is
The lack of a :from-var indicates that baz is referenced from the top level. Perhaps this is fine and should stay - however, I would like to see the following (or similar) included.
To upvote this issue, give it a thumbs up. See this list for the most upvoted issues.
Is your feature request related to a problem? Please describe.
I would like to use the
:var-usages
data from the:analysis
to perform static analysis.Currently, it appears that no information about referenced vars is preserved for
defmethod
expressions and while referenced vars are preserved fordefmulti
expressions, the fact that the source var is a multimethod is not.As a concrete example, assuming that I have the following namespace
If I run the following analysis
I get the following under
[:analysis :var-usages]
(I have removed some keys to reduce noise){:name defn, :from my-ns, :macro true, :to clojure.core}
{:name foo, :from my-ns, :from-var bar, :to my-ns}
{:name defn, :from my-ns, :macro true, :to clojure.core}
{:name identity, :from my-ns, :from-var baz, :to clojure.core}
{:name defmulti, :from my-ns, :macro true, :to clojure.core}
{:name baz, :defmethod true, :dispatch-val-str ":call-foo", :from my-ns, :to my-ns}
{:name foo, :from my-ns, :to my-ns}
{:name defmethod, :from my-ns, :macro true, :to clojure.core}
From this we can see that
foo
is called from varbar
(entry 2) and thatidentity
is called from the varbar
(entry 4).Note that in entry 4
baz
is not marked as a multimethod. The fact that theidentity
function is (part of) the dispatch-fn for the multimethod is not captured. Moreover, it is not shown thatfoo
is also called from the multimethodbaz
with dispatch-val:call-foo
.Entry
6
suggests thatbaz
is called from the top level (there is no:from-var
).Ideally, multimethods could be handled in a more nuanced way for the var-usage analysis.
Describe the solution you'd like
A clear and concise description of what you want to happen.
I would like entry 4 in the
:var-usages
to include the key/val pair:defmulti true
To indicate thatidentity
must have been referenced from the dispatch-fn. (I don't think there would be another reason to reference a var here?)Entry 6 is slightly more problematic. Currently it is
The lack of a
:from-var
indicates thatbaz
is referenced from the top level. Perhaps this is fine and should stay - however, I would like to see the following (or similar) included.I am not sure if this would make sense coexisting with entry 6?
Describe alternatives you've considered
A clear and concise description of any alternative solutions or features you've considered.
Writing my own tool for performing such analysis.
Additional context
Add any other context or screenshots about the feature request here.
Open to looking into this, but not sure about the scope/how difficult it would be?
The text was updated successfully, but these errors were encountered: