Logging mechanism

[jslee02]

Chimera currently doesn't provide a way to redirect printing warnings to std::cout or std::cerr. This is less convenient to catch the warnings in unit testing.

Possible solutions (from simple to sophisticated):

1. Parameterize the target output stream so that we can set it other than std::cout and std::cerr. The we can pass a custom output stream that is designed for debugging. The custom output stream would simply collect the warnings in a list so it would have to parse the raw string.
2. Introduce logging mechanism like spdlog. This way we could use various logger (e.g., std::err logger, file logger, even a custom logger that collects the error instances). One additional advantage of this would be that we could encode error code in a log instance so we can more easily filtering, grouping, and lookup logs for unit testing. I'm thinking of APIs something like:

// before running the ClangTool
chimera::log::set_default_logger(chimera::log::FileLogger("<path>"));
chimera::log::set_default_logger(chimera::log::StdCoutLogger());
chimera::log::set_default_logger(chimera::log::StdCerrLogger());
chimera::log::set_default_logger(chimera::log::DebugLogger());

// emitting warning using default logger
chimera::log::warnning(chimera::ErrorCode::B012, "Skipped function <...> because ...");  // or
chimera::log::log(chimera::log::Level::WARNING, chimera::ErrorCode::B012, "Skipped function <...> because ...");

// emitting error
chimera::log::error(chimera::ErrorCode::B013, "Skipped method <...> because ...");

// emitting log using specific logger
std_cout_logger->warn(chimera::ErrorCode::B012, "Skipped function <...> because ...");
std_cerr_logger->error(chimera::ErrorCode::B013, "Skipped method <...> because ...");

// debug logger
class DebugLogger : public chimera::log::Logger {
public:
  bool HasError() const;
  bool HasWarning() const;

  bool HasErrorCode(chimera::log::ErrorCode) const;
  std::vector<Log> GetLogsWithErrorCode(chimera::log::ErrorCode) const;
}

[psigen]

This is fairly advanced logic for a command line tool. Most CLI tools would not support this level of granularity.

Is the nature of this to check for certain printed output in the unit testing framework?

[jslee02]

Is the nature of this to check for certain printed output in the unit testing framework?

Yes, that's the biggest motivation. It's currently not easy to unit-test for each warnings for even a simple case. I'm open to simpler way.

[jslee02]

Related issue: #76, #115, #149