New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Don't fail analysis due to unknown tagged literals #32
Comments
@holyjak I've moved this issue to the cljdoc-analyzer project which is the standalone project that takes care of analyzing Clojure and ClojureScript sources. I hunch is that it fails when requiring the namespace. A good next step would be adding a test to the metagetta module and verify that it fails. It looks like Kaocha is set up for this project in which case I think you should be able to run tests with I hope this helps. Once we have a failing test case I think we can explore using |
I have discovered that the solution is not complete. When, inside the analyzer's (analyze {:project "com.fulcrologic/fulcro" :version "3.4.16"})
The error comes from So it seems that we are trying to "embed the TaggedLiteral in code". So replacing unknown tag literals with this is not sufficient. But the tests succeed so I am unsure what is different here. What is also surprising is that I do not see any use of |
the commit above fixes the problem |
Fix #32: unknown tagged literals -> valid code
Currently, if the analyzed source code contains an unknown tagged literal, an exception is thrown and the analysis fails. However, most of the time, we don't need to have a perfect representation of the code, we only care about top-level functions and such so, 99.9% we shouldn't really care about those tagged literals and their values.
Possible solutions
1. Detect and apply data readers from the project
We know where data readers are declared, in
data_readers.clj[c]
at the top of the classpath, so we could check for that and apply those data readers, f.ex. by rebinding*data-readers*
or by supplying the map of data readers to the reader that reads the code (if supported; if we use tools.reader, there is*data-readers*
).Pros: We would see the code that the runtime sees.
Cons: More work on our part.
2. Ignore unknown tagged literals without failing
Alternatively, we could define a fallback data reader that simply replaces everything unknown with nil, that would be I assume good enough for analyzing the code and simple.
From the docs:
The text was updated successfully, but these errors were encountered: