Feature/ast visualization

[Process-ing]

Description

This PR adds a visualization tool that allows the visual mapping of the source code to the AST. This tool was develop on the context of the summer internship with topic "[CSE01] Visual Mapping of Source Code to Abstract Syntax Tree (AST)", from the INESC TEC Summer Internship 2024 programme.

To be precise, this PR creates the specialization of the tool for Clava. So, this PR must be merged before merging this one.

Changes Made

• Added specializations of GenericVisualizationTool and GenericAstConverter, defined in the LARA API, that implements the needed operations for the Clava compiler.

How Has This Been Tested

This was mainly tested manually. As the time of writing, I am still doing some final stress testing for possible bugs, so you may see some minor fixes in the future.

To run the tool, in the script fed to Clava, import VisualizationTool and call await VisualizationTool.visualize() on the point of execution where you want to analyze the AST.

[joaobispo]

Probably this API, being part of Clava API, should be in the folder src-api/clava/visualization.

[joaobispo]

It is possible to add automatic tests? For the web interface is complicated, but for instance, it is possible to have tests for the output of ClavaAstConverter.getCode().

[Process-ing]

About the folder, it boils down to the same thing I responded in this comment.

About the automatic tests, I do think that they are possible, just not extremely necessary since almost any problem will be noticeable in the web interface and in the console logs. But I do have some considerations:

• To test getPrettyHtmlCode, since this function returns HTML code in a string, to better parse and analyze it, I would recommend using JSDOM, which implements utilities to create a headless DOM, allowing us to perform HTML queries (like with querySelectorAll) in Node.js without a browser. This lets us more easily test the existence of IDs, elements with certain contents, and more.
• I would advise (for integration tests) to avoid performing perfect matches in the tests (like getPrettyHtmlCode returning an exact string for a given AST), since most methods will produce different results depending on the AST provided and some minor details of the AST converter. For example, modifying the code of a join point slightly would most likely fail a test with perfect matches, and adding a new entry to the information of a join point type should be harmless and not worth testing. Because of this, I would recommend to follow an approach similar to property-based testing, providing some inputs and only expecting the results to follow some properties (e.g. getPrettyHtmlCode should have the same code of the woven file after removing the HTML tags, all join points should have at least one corresponding HTML element, getToolAst should convert all join points and maintain the order, etc.)