On 28/11/13 20:25, Joseph Rushton Wakeling wrote:
assert statements in the main body of code (not just the unittests) are
enabled with -release if -unittest is turned on, but in- and out-contracts are
still stripped.
After consideration, I think that this is the real issue here: it's not a
pro
On Thursday, November 28, 2013 20:08:34 Dicebot wrote:
> On Thursday, 28 November 2013 at 19:01:40 UTC, Jonathan M Davis
>
> wrote:
> > The closest you would get would be
> >
> > version(assert) {}
> > else { /* release */ }
> >
> > - Jonathan M Davis
>
> Which does not work if you also have "-
On 28/11/13 20:08, Dicebot wrote:
Which does not work if you also have "-unittest" ;)
Plus, assert statements in the main body of code (not just the unittests) are
enabled with -release if -unittest is turned on, but in- and out-contracts are
still stripped. An oversight, perhaps?
I don't
On Thursday, November 28, 2013 18:28:55 Gary Willoughby wrote:
> On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
> > I don't know what is the proper way to handle this but current
> > situation is clearly worth a bugzilla entry. It is just weird.
>
> Maybe this is intended behaviour
On Thursday, 28 November 2013 at 19:01:40 UTC, Jonathan M Davis
wrote:
The closest you would get would be
version(assert) {}
else { /* release */ }
- Jonathan M Davis
Which does not work if you also have "-unittest" ;)
On Thursday, November 28, 2013 19:53:48 Dicebot wrote:
> On Thursday, 28 November 2013 at 18:26:15 UTC, Joseph Rushton
>
> Wakeling wrote:
> > I think it may actually be a bug in whether -release implies
> > version(release).
> > Try out the attached code. (r)dmd -release release.d produces
> > a
On Thursday, November 28, 2013 17:40:55 Dicebot wrote:
> I have quickly tested it and looks like asserts are not removed
> from unittest blocks in release builds, only from normal code.
> Which does not seem to be documented on dlang.org but was
> probably introduced exactly to prevent existing tes
On Thursday, 28 November 2013 at 18:26:15 UTC, Joseph Rushton
Wakeling wrote:
I think it may actually be a bug in whether -release implies
version(release).
Try out the attached code. (r)dmd -release release.d produces
an executable
that still reports that release mode is disabled.
There is
On 28/11/13 19:01, Dicebot wrote:
On Thursday, 28 November 2013 at 17:28:56 UTC, Gary Willoughby wrote:
On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
I don't know what is the proper way to handle this but current situation is
clearly worth a bugzilla entry. It is just weird.
M
On Thursday, 28 November 2013 at 17:28:56 UTC, Gary Willoughby
wrote:
On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
I don't know what is the proper way to handle this but current
situation is clearly worth a bugzilla entry. It is just weird.
Maybe this is intended behaviour to
On Thursday, 28 November 2013 at 17:22:20 UTC, Dicebot wrote:
I don't know what is the proper way to handle this but current
situation is clearly worth a bugzilla entry. It is just weird.
Maybe this is intended behaviour to handle testing AssertErrors
in unit tests? How else could you test the
I don't know what is the proper way to handle this but current
situation is clearly worth a bugzilla entry. It is just weird.
On Thursday, 28 November 2013 at 16:40:57 UTC, Dicebot wrote:
I have quickly tested it and looks like asserts are not removed
from unittest blocks in release builds, only from normal code.
Which does not seem to be documented on dlang.org but was
probably introduced exactly to prevent existing
On 28/11/13 17:59, Dicebot wrote:
version(assert) is negated by -unittest at all actually:
import std.stdio;
void main()
{
version ( assert )
{
writeln("errr");
}
}
$ rdmd -release test.d
$ rdmd -release -unittest test.d
errr
That is so bad >_<
Aack!! :-\
And to
version(assert) is negated by -unittest at all actually:
import std.stdio;
void main()
{
version ( assert )
{
writeln("errr");
}
}
$ rdmd -release test.d
$ rdmd -release -unittest test.d
errr
That is so bad >_<
On 28/11/13 17:40, Dicebot wrote:
I have quickly tested it and looks like asserts are not removed from unittest
blocks in release builds, only from normal code. Which does not seem to be
documented on dlang.org but was probably introduced exactly to prevent existing
tests from breaking in release
On 28/11/13 17:40, Dicebot wrote:
I have quickly tested it and looks like asserts are not removed from unittest
blocks in release builds, only from normal code. Which does not seem to be
documented on dlang.org but was probably introduced exactly to prevent existing
tests from breaking in release
P.S. version(assert) does not seem to be working at all
I have quickly tested it and looks like asserts are not removed
from unittest blocks in release builds, only from normal code.
Which does not seem to be documented on dlang.org but was
probably introduced exactly to prevent existing tests from
breaking in release mode. I have just learned somet
On 28/11/13 17:20, Dicebot wrote:
assert(false) is special and never removed, don't use it for testing assert code
: http://dlang.org/expression.html#AssertExpression
Seems to make no difference if I replace it with
int i = 1;
assertThrown!AssertError(assert(i == 3));
... and tweak th
assert(false) is special and never removed, don't use it for
testing assert code :
http://dlang.org/expression.html#AssertExpression
On 28/11/13 17:04, Dicebot wrote:
Oh, oops, I thought your issue is exactly other way around, sorry. That looks
like an issue in assertThrown implementation. probably worth a bugzilla entry.
It's a bit mysterious. Consider this minimal example:
unittest
{
import std.exception,
On Thursday, 28 November 2013 at 16:01:06 UTC, Joseph Rushton
Wakeling wrote:
On 28/11/13 16:58, Joseph Rushton Wakeling wrote:
But even with version(assert) conditionals in place, the
assertThrown is still called.
Come to that, even if I do:
version(release) {} else { assertThrown(...);
On 28/11/13 16:58, Joseph Rushton Wakeling wrote:
But even with version(assert) conditionals in place, the assertThrown is still
called.
Come to that, even if I do:
version(release) {} else { assertThrown(...); }
then the assertThrown is _still_ called even in release mode.
On 28/11/13 16:48, Dicebot wrote:
I think using assert for unittests is a mistake if you ever going to test
release builds. `std.exception.enforce` or something similar is a better match.
I'm testing an in-contract, as it happens.
The point is that code inside version(assert) should only be in
I think using assert for unittests is a mistake if you ever going
to test release builds. `std.exception.enforce` or something
similar is a better match.
Hello all,
Some unittests I've been writing for Phobos involve using
assertThrown!AssertError to check that assert failures are indeed triggered
where they should be.
Surprise surprise, this fails on the release unittest build, because of course
the assertion statements are stripped out. I
27 matches
Mail list logo
