Closed mosherubin closed 2 years ago
The implementation of this issue is PR #41.
Kunal Tyagi's email response (4 July 2022):
To be honest, I've been looking at how to handle the tool as a kind of parse with a bunch of different callbacks which call the logging module.
This would allow users to basically decorate their callbacks and have a verbose output allowing them to debug, control the verbosity, output location and style as well as run their custom rulesets.
Sadly, I've not been able to focus fully on this. The design I've in mind has a few too many moving parts, and I've been a bit busy in general. The customization points are:
- logging format (what details to log)
- logging location (stdout, file)
- logging stye (color, no color, etc.)
- what to log (how detailed)
- when to log (pre rule, post rule)
- how to let users add info to logs (for future reference or debugging where pdb is more complicated than a simple print)
The other questions are mere nomenclature once the big ones are satisfied.
My response (4 July 2022):
Thank you for the PR code review comments re PR #35 - I hope to get to them over the next day or two.
No doubt about it, you are a real toolsmith and software designer! I would be happy to help out with some of the work related to overhauling the callback system, if I can fully understand your advances and elegant design. As you yourself intimate, it will be some time before the internal design can be implemented. In the meantime, please put your ideas in an issue so I can read, comment, and understand what you have in mind. I would be more than happy to help out here.
Until that time, there is a great need for a "-ast-dump"-like option which I would like to push. The questions about locations and names are important ones in the meantime. When your callback design is implemented, we can always change the tool. Can you give me guidelines on how to push the tool code in the meantime?
The request
NsiqCppStyle should provide a convenient and easy-to-use tool to show precisely which rule callback functions will be invoked for a given sequence of source code.
Background
Writing an NsiqCppStyle rule requires understanding which callback functions will be invoked when the engine is processing a known sequence of source code. Currently, knowing which callback functions to take advantage of can be tedious. In addition, a rule writer may not be aware of which callback functions are actually invoked, often missing an elegant method of implementing a rule.
The request is to write a tool that, given a snippet of source code, shows the rule writer the precise set of callback functions invoked, and their order. Each callback function displayed should provide important information such as the token type and value, any existing context stack, and other valuable data passed via the callback function.
The tool is written in the style of an NsiqCppStyle rule file, hooking in to the callback function system.
This tool is similar to Clang's
ast-dump
command line option.Example
Suppose we want to see what callback functions NsiqCppStyle will invoke for the following C++ source code:
Here is what the above tool's output might look like:
A few comments:
Points to Consider
[RULE|TOOL|UTIL]_nn_nn_text
or some other standard? If the user standard, what number corresponds to NsiqCppStyle-related rule files?nsiqcppstyle -r > filefilter.txt
. We need to modify the "-r" option NOT to output tool/util scripts, as they are not rules for finding warnings in C++ source code.