basically runs miri with the option defined in MiriOpt, and collect output from it.

remember to add tests for serializing to make sure each field will be successfully serialized into string.

For example, this trait will have at least a method called check or something to invoke the actual command of a specific tool's option, and collect its output.

The app needs to read a local config file from the user, which will be a JSON file.

Remember to add tests for parsing to ensure each config option will be de-serialized into the struct.

Summary

Currently, eunomia checks code by invoking other tools such as clippy, sanitizer etc.

Therefore, there will be false positive cases almost for certain. If the problematic code can be detected by rustc/clippy lints, users could just add a allow[xxx] to ignore it. But if it was detected by other tools that doesn't have such control, then the output will contains a false positive error result, this might cause a huge problem if eunomia was set in some project's ci and causing it to fail.

In that case, we need a mechanism to ignore potential false positive results, this could be done by reading a configuration file from src code root directory (such as clippy.toml);
Or, read the source file that have specific attribute macro (such as #[cfg(eunomia)]) with another attributes such as #[eunomia(allow = "xxxxx")] to ignore a case called xxxxx for the next line of code.

The first method should be more achiveable, since some check result might not even have a line information, not to mention some of the result (specifically the output of lint check in clippy::cargo group) cannot be controlled by the second method.

this includes dogfood tests, meaning that we need to be able to:

1. compile this tool
2. run this tool, on the source code of this tool 🤣

simply adding an option to run cargo fmt --check --all to github action should do the trick,
and it would really help improving the quality of the code base imo.

Using clap at this stage is preferred, since we might not have enough time to implement it on our own, but do note that we might need to ditch clap in the future, so try to make the design less clap-dependent. Therefore, using a struct with its derive macro is preferable, and if we want to implement argparser in our own we don't need to change much of the existing syntax.

Basic option to implement:

1. -h|--help: show a help messages describe what this tool does and for each command options.
2. -V|--version: show the current app version.
3. --rule-file <FILE>: set the path to the checks configuration file, which needs to be an existing file.
4. --src-file <FILE>: set the path to the source code file that needs to be checked.
5. --output <PATH>: set the path to the output file, doesn't need to exist as the program will attempt to create one.

For example:

"guidelines": [
    "id": "xxx",
    "name": "xxxxx",
    "clippy": [
        {
            "level": "warn",
            "lint": "xxxxxx"
        }
    ]
]

meaning that a guideline item with id, and name could be checked by enabling a warning level clippy lint called xxxxxx

basically runs cargo build, or build a certain rust file with rustc with the option defined in ClippyOpt, and collect output from it.

this should be pretty strait forward, it basically runs clippy with the option defined in ClippyOpt, and collect output from it.

As described, a rustbot will be very help for to manage issue/PRs.