Previously, any warnings/errors were emitted directly to stderr by Clang and our WebCLReporter. Now these are collected in a structured form by a new WebCLDiag component and exposed through the API. The CLI validator uses the API to print out the log to stderr in a pretty similar format so existing tests which check for certain errors on invalid source etc continue to work.
Messages are currently quads with:
severity (enum: note/warning/error)
text (as formatted by Clang)
full source code that caused the error (same as input source for preprocessing errors, transformed source otherwise)
offset/length of the part of the source relevant to the error
This is exposed through the following API:
// Get number of validation log messages (notes, warnings, errors)
CLV_API cl_int CLV_CALL clvGetProgramLogMessageCount(
clv_program program);
// Severity level of a validation log message
typedef enum {
// Informative note
CLV_LOG_MESSAGE_NOTE,
// Warning
CLV_LOG_MESSAGE_WARNING,
// Error
CLV_LOG_MESSAGE_ERROR
} clv_program_log_level;
// Get severity level of a validation log message
CLV_API clv_program_log_level CLV_CALL clvGetProgramLogMessageLevel(
clv_program program,
cl_uint n);
// Get text of a validation log message
CLV_API cl_int CLV_CALL clvGetProgramLogMessageText(
clv_program program,
cl_uint n,
size_t buf_size,
char *buf,
size_t *size_ret);
// Determine if the given validation log message has associated source code
CLV_API cl_bool CLV_CALL clvProgramLogMessageHasSource(
clv_program program,
cl_uint n);
// Get the start offset of the relevant part of the source code
CLV_API cl_long CLV_CALL clvGetProgramLogMessageSourceOffset(
clv_program program,
cl_uint n);
// Get the length of relevant part of the source code
CLV_API size_t CLV_CALL clvGetProgramLogMessageSourceLen(
clv_program program,
cl_uint n);
// Get (a substring of) the source code associated with the log message
CLV_API cl_int CLV_CALL clvGetProgramLogMessageSourceText(
clv_program program,
cl_uint n,
cl_long offset, // 0 for full source
size_t len, // size_t(-1) for full source
size_t buf_size,
char *buf,
size_t *size_ret);
Unfortunately not all code in Clang uses the diagnostics system, so e.g. the error/warning counts are still always emitted to stderr. This would need a fix in clang.
Still missing is the location in the original input source that caused the diagnostic. The line numbers are currently lost in our rewrite/reparsing passes. This could be fixed by using Clang preprocessor #line directives suitably, at which point original source line numbers could be added to the API for better graphical debugging etc.
Previously, any warnings/errors were emitted directly to stderr by Clang and our WebCLReporter. Now these are collected in a structured form by a new WebCLDiag component and exposed through the API. The CLI validator uses the API to print out the log to stderr in a pretty similar format so existing tests which check for certain errors on invalid source etc continue to work.
Messages are currently quads with:
This is exposed through the following API:
Unfortunately not all code in Clang uses the diagnostics system, so e.g. the error/warning counts are still always emitted to stderr. This would need a fix in clang.
Still missing is the location in the original input source that caused the diagnostic. The line numbers are currently lost in our rewrite/reparsing passes. This could be fixed by using Clang preprocessor #line directives suitably, at which point original source line numbers could be added to the API for better graphical debugging etc.