sammccall added a comment. In D146591#4213319 <https://reviews.llvm.org/D146591#4213319>, @xazax.hun wrote:
> While I am OK with this approach, I wonder if it would be too much work to > split the HTML generation and emitting data up. E.g., the logger could emit > YAML or JSON that could be parsed by a python script to create the HTML (or > the HTML itself could use JS to parse it and generate the DOM). This is definitely doable. I think the main downside is more JS complexity: emitting JSON is easy, turning it into a view means some sort of templating (micro)framework, probably. (I find it important that the output is directly viewable without running extra tools, and we're not pulling in big deps. So this probably means some custom JS) > This would have a couple of advantages like: > > - People could add additional visualizations or other tools like querying > program states more easily just consuming the JSON/YAML file > - Other static analysis tools could produce similar YAML/JSON so your > visualization could potentially work for other analysis tools. E.g., I think > people were working on a dataflow analysis framework for MLIR. Definitely. To realize these advantages, the data model needs to be generic enough and stable enough that it's actually useful with different producers/consumers. (e.g. does the MLIR dataflow framework have the same idea about how the analysis timeline relates to the CFG and elements within it? And if we want to show the clang AST or the StorageLocation/Value graph, what's the non-clang::dataflow-coupled way to model that?) This seems useful but also a pretty large project in itself - I don't think I have the experience or bandwidth to take it on. (My primary goal is nullability analysis, I need to spend some more time on that directly to understand deeper requirements about debugging these things). One halfway point is to move the data into JSON, move most of the HTML into a static file, and use JS to mash them together - without exposing the JSON separately or attempting to properly decouple it from the generator/visualization, but leaving us closer to doing that later. Do you think that's valuable? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D146591/new/ https://reviews.llvm.org/D146591 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
