Difference between revisions of "DIP83"
Line 105: | Line 105: | ||
{ | { | ||
version(assert) | version(assert) | ||
− | |||
{ | { | ||
− | throw AssertError("Failed arithmetic assert: " ~ | + | const lhsValue = lhs(); |
+ | const rhsValue = rhs(); | ||
+ | if (mixin("lhsValue" ~ binOp ~ "rhsValue")) | ||
+ | { | ||
+ | throw AssertError("Failed arithmetic assert: " ~ lhsValue ~ " " ~ binOp ~ " " ~ rhsValue); | ||
+ | } | ||
} | } | ||
} | } |
Revision as of 10:12, 2 October 2015
Title: | Configurable Assert Diagnostics |
---|---|
DIP: | 83 |
Version: | 1 |
Status: | Draft |
Created: | 2015-10-01 |
Last Modified: | 2015-10-2 |
Author: | Per Nordlöw |
Links: |
Abstract
Allow for assert's to do pretty printing of its failing expression when flagged for in call to compiler. Printing is configurable via specific sets of (template) function overloads.
Rationale
Failing asserts in unittests currently given no hints about the reason why a test failed. To aid the developer in debugging the failing assert
- binary expressions such as assert(x == y) should, for instance, print the values of x and y and
- unary expressions such as assert(!x) should, for instance, print the value of x.
This extra, so called, pretty printing can be enabled by the developer by changing the compilation flags (DFLAGS) to calls to rdmd, dub, scons etc upon failure with existing behavior of -unittest for a specific failing module. This will be more convenient than explicitly adding the prints of the left-hand-side expression lhs and right-hand-side expression rhs directly before the call to the failing assert.
Description
This DIP proposes to add library-level-configurable diagnostics to failing calls to assert(expr) typically called from within unittest-blocks.
This diagnostics is activated only when DMD is called with a specific command line flag, say -unittest=verbose.
If DMD is called with this flag it will rewrite all assert expressions (AssertExpr in dmd source) such as
assert(lhs BINOP rhs)
with
assertBinOp(__FILE__, __LINE__, __COLUMN__, "BINOP")(lhs, rhs)
where
void assertBinOp(string file, uint line, uint column, string binOp)(L, R)(lazy L lhs, lazy R rhs);
and similarly for unary expressions replace
assert(UNOP lhs)
with
assertUnOp(__FILE__, __LINE__, __COLUMN__, UNOP)(lhs, rhs)
where
void assertUnOp(string file, uint line, uint column, string unop)(L, R)(lazy L lhs, lazy R rhs);
The default implementation of assertBinOp (preferrably in druntime) would be a function that mimics the current behaviour of assert(lhs BINOP rhs) typically as
import core.exception : AssertError;
void assertBinOp(string file, uint line, uint column, string binOp)(L, R)(lazy L lhs, lazy R rhs, string message)
{
version(assert)
if (mixin("lhs" ~ binOp ~ "rhs"))
{
throw AssertError("Failed assert");
}
}
The Phobos-developer can then do what he likes with the information he needs in the extra arguments in specific templated overloads of assertBinOp.
This specific behaviour could be extendable by adding (typically templated) overloads of assertBinOp for specific sets of types (concepts).
For instance, better diagnostics for comparing arithmetic types can be realized through the overload
import std.traits : isArithmetic;
void assertBinOp(string file, uint line, uint column, string binOp)(L, R)(lazy L lhs, lazy R rhs, string message)
if (isArithmetic!L && isArithmetic!R)
{
version(assert)
{
const lhsValue = lhs();
const rhsValue = rhs();
if (mixin("lhsValue" ~ binOp ~ "rhsValue"))
{
throw AssertError("Failed arithmetic assert: " ~ lhsValue ~ " " ~ binOp ~ " " ~ rhsValue);
}
}
}
In this way D would get the extendability we want in testing-frameworks such as std.experimental.testing (https://github.com/D-Programming-Language/phobos/pull/3207) without adding a new assert-overload-set and without sacrifycing default memory usage in DMD/Phobos unittests.
Further, this solution enables the possibility to provide fancy diagnostics behaviour in assertBinOp for failing array/range or aggregate (struct or class) comparisons. This diagnostics could also have different pretty printing backends such as HTML.
For example a failing
assert([1,2,3] == [1,2,4]);
could pretty-print
([1,2,3][2] is 3) != ([1,2,4][2] is 4)
or for aggregates a failing
struct A { int x, y; }
auto a = A(1,2);
auto b = A(1,3);
assert(a == b);
could pretty-print
(a.y is 2) != (b.y is 3)
Parts of the solution list at
https://issues.dlang.org/show_bug.cgi?id=5547#c3
including rewriting/expansion of AssertExpr could probably reused.
Impact
Copyright
This document has been placed in the Public Domain.