=== Log Statements ===
==== Log Format Must Match the Format of a Regular Expression ====
 * '''Symbolic Name in XML Configuration''': checkLogStatementFormat
 * '''Dependant Tags in XML Configuration''': logFormatRegExp, checkLogItemFormat, processSubsequentLogStatementsAsOne

The check inspects the string in each log statement and matches it against a given regular expression. The predefined regular expression corresponds to the current ETSI guidelines. The regular expression can be adapted and customized for each profile however by changing the content of the '''logFormatRegExp''' tag in a profile of the XML configuration. In addition, the first regexp group is matched against the name of outer compound of the log statement, i.e., the function, testcase, or altstep name. If the first group is empty, the latter additional check will be ignored. That means, if T3Q shall not check for the containing construct, there must be an artificial empty first group in the specified regexp.

The current default regular expression is:

{{{
[\*]{3}\s([fta]_[a-zA-Z0-9]+?):\s(INFO|WARNING|ERROR|PASS|FAIL|INCONC|TIMEOUT):\s.*?[\*]{3}
}}}
The '''checkLogStatementFormat''' setting enables checking the ''whole'' log statement where multiple log items within a single log statement are joined as one. In case of string concatenation and/or use of non-chastring elements (e.g. variable references, constant references, parameter references, or function calls), all non-charstring elements are currently substituted by an empty string. Note that charstring elements used as parameters in e.g. function calls currently will also be taken into consideration when checking the log statement format.

For individual log items, the '''checkLogItemFormat''' setting can be enabled instead. The same regular expression is used for checking individual log items. Note that even though the same regular expression is used, both checks are independent, meaning both can be enabled at the same time, with one checking the individual log items within a log statement and the other combining those log items and checking their concatenation (ignoring non-charstring elements as noted above). Due to possible confusion introduced by this additional check and its questionable usefulness, it should be considered deprecated and will be removed in future releases.

By enabling the '''processSubsequentLogStatementsAsOne''' setting, subsequent log statements can be combined and analyzed as one (again ignoring variables within log statements), in a way similar to how log items are analyzed together within a log statement. This setting has no effect if '''checkLogStatementFormat''' is disabled.

Note that subsequent log statements (without any other statements in between) are always combined when the '''processSubsequentLogStatementsAsOne''' setting is enabled. This may in some cases lead to unreliable results, if, for example, one well-formed log statement is followed by another not well-formed one, the combination of the two may still yield a valid log statement with the setting enabled.

Note also if the '''processSubsequentLogStatementsAsOne''' setting is enabled, the subsequent log statements that are combined together are analyzed as a bundle starting with the first log statement in the sequence, meaning that the subsequent log statements are not analyzed individually again.

'''Example:'''

[[Include(source:trunk/t3q-examples/checkLogFormat/checkLogFormat.ttcn3, text/x-rst)]]

==== External Function Invocation Must Be Preceded By A Log Statement ====
 * '''Symbolic Name in XML Configuration''': checkExternalFunctionInvocationPrecededByLogStatement
 * '''Dependant Tags in XML Configuration''': -

Checks whether any invocation of an external function is preceded by a log statement. The examples shall generated warnings for all the invocations that do not have a log statement preceding them directly (tagged as ''bad'').

'''Example:'''

[[Include(source:/trunk/t3q-examples/checkExternalFunctionInvocationPrecededByLogStatement/checkExternalFunctionInvocationPrecededByLogStatement.ttcn3, text/x-rst)]]

Note that if an external function is called within a constant or a template definition on the module level, an information message will be provided that in such a context it is not possible to have a log statement following it. Note also that if a function definition cannot be resolved, a corresponding information message will be provided as well.

==== Inconclusive or Fail Setverdict Statement Must be Preceded by a Log Statement ====
 * '''Symbolic Name in XML Configuration''': checkInconcOrFailSetVerdictPrecededByLog
 * '''Dependant Tags in XML Configuration''': -

Checks whether setverdict statements that set inconc or fail verdicts are preceded by log statements. In the example, the first alt statement represents the expected syntax whereas the second alt statement fails to have log statements before the two existing  fail and inconc setverdict statements.

'''Example:'''

[[Include(source:trunk/t3q-examples/checkInconcOrFailSetVerdictPrecededByLog/checkInconcOrFailSetVerdictPrecededByLog.ttcn3, text/x-rst)]]