www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is it acceptable to not parse unittest blocks when unittests are

reply deadalnix <deadalnix gmail.com> writes:
I was wondering. When uniitests aren't going to run, it may be 
desirable to skip parsing altogether, just lexing and counting 
braces until the matching closing brace is found.

Obviously, this means that no error will be found in unittests 
blocks. That can contain pretty much anything that lex, so it's 
even more lax than what's allowed inside a static if.

Is that an acceptable tradeof ?
Mar 29 2017
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 29/03/2017 12:16 PM, deadalnix wrote:

 I was wondering. When uniitests aren't going to run, it may be desirable
 to skip parsing altogether, just lexing and counting braces until the
 matching closing brace is found.

 Obviously, this means that no error will be found in unittests blocks.
 That can contain pretty much anything that lex, so it's even more lax
 than what's allowed inside a static if.

 Is that an acceptable tradeof ?


I see no reason to not to treat it as:

version(unittest) {
	void func_xxxx() {
		...
	}
}

Which is basically what you said.
Mar 29 2017
parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 29 March 2017 at 11:22:59 UTC, rikki cattermole 
wrote:

 Which is basically what you said.


It isn't. version needs to be parsed and thus, grammatically 
valid.
Mar 29 2017
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/03/2017 1:16 PM, deadalnix wrote:

 On Wednesday, 29 March 2017 at 11:22:59 UTC, rikki cattermole wrote:

 Which is basically what you said.


 It isn't. version needs to be parsed and thus, grammatically valid.


Hmm, well that is another thing that could be disabled to shave some 
time off the build times I suppose.
Mar 29 2017
prev sibling next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:

 I was wondering. When uniitests aren't going to run, it may be 
 desirable to skip parsing altogether, just lexing and counting 
 braces until the matching closing brace is found.

 Obviously, this means that no error will be found in unittests 
 blocks. That can contain pretty much anything that lex, so it's 
 even more lax than what's allowed inside a static if.

 Is that an acceptable tradeof ?


I would not do this trade off,
It's highly surprising since no other language feature works that 
way.
Also parsing is rather cheap.
Mar 29 2017
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:

 I was wondering. When uniitests aren't going to run, it may be 
 desirable to skip parsing altogether, just lexing and counting 
 braces until the matching closing brace is found.


Sorry, is this not already the case?

$ dmd test.d
$ cat test.d
void main()
{
	import std.stdio;
	writeln("Hello, world!");
}


unittest
{
	foo bar {} baz more-syntax!errors)blah
}
$ dmd test.d
$ ./test
Hello, world!
Mar 29 2017
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:

 I was wondering. When uniitests aren't going to run, it may be 
 desirable to skip parsing altogether, just lexing and counting 
 braces until the matching closing brace is found.


 Sorry, is this not already the case?

 $ dmd test.d
 $ cat test.d
 void main()
 {
 	import std.stdio;
 	writeln("Hello, world!");
 }


 unittest
 {
 	foo bar {} baz more-syntax!errors)blah
 }
 $ dmd test.d
 $ ./test
 Hello, world!


Surprise!
Mar 29 2017
prev sibling next sibling parent reply Vladimir Panteleev <thecybershadow.lists gmail.com> writes:
On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:

 I was wondering. When uniitests aren't going to run, it may be 
 desirable to skip parsing altogether, just lexing and counting 
 braces until the matching closing brace is found.


 Sorry, is this not already the case?


https://github.com/dlang/dmd/pull/4704
Mar 29 2017
parent Claude <no no.no> writes:
On Wednesday, 29 March 2017 at 19:43:52 UTC, Vladimir Panteleev 
wrote:

 On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev 
 wrote:

 On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:

 I was wondering. When uniitests aren't going to run, it may 
 be desirable to skip parsing altogether, just lexing and 
 counting braces until the matching closing brace is found.


 Sorry, is this not already the case?


 https://github.com/dlang/dmd/pull/4704


To quote Walter Bright from that PR, unittest can contain invalid 
code ONLY if you never compile with -unittest (obviously), -D or 
-H.

It looks consistent to me: just don't parse it in release mode.
Mar 30 2017
prev sibling parent reply deadalnix <deadalnix gmail.com> writes:
On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev 
wrote:

 Sorry, is this not already the case?

 $ dmd test.d
 $ cat test.d
 void main()
 {
 	import std.stdio;
 	writeln("Hello, world!");
 }


 unittest
 {
 	foo bar {} baz more-syntax!errors)blah
 }
 $ dmd test.d
 $ ./test
 Hello, world!


Alright then, it looks like it is :)

I was asking for SDC.
Mar 30 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 30 March 2017 at 14:28:41 UTC, deadalnix wrote:

 On Wednesday, 29 March 2017 at 19:32:50 UTC, Vladimir Panteleev 
 wrote:

 Sorry, is this not already the case?

 $ dmd test.d
 $ cat test.d
 void main()
 {
 	import std.stdio;
 	writeln("Hello, world!");
 }


 unittest
 {
 	foo bar {} baz more-syntax!errors)blah
 }
 $ dmd test.d
 $ ./test
 Hello, world!


 Alright then, it looks like it is :)

 I was asking for SDC.


SDC has the goal to be more principled.
And Not to be Mr. fast and loose, right ?
If a file parses it'd better be syntactically correct!
All of it.
Mar 30 2017
parent reply Dukc <ajieskola gmail.com> writes:
On Thursday, 30 March 2017 at 17:22:20 UTC, Stefan Koch wrote:

 SDC has the goal to be more principled.
 And Not to be Mr. fast and loose, right ?
 If a file parses it'd better be syntactically correct!
 All of it.


Just an idea, but could the solution for SDC be to enable 
unittests by default, disabling them would be explicit? That 
would sure make using it alot more principled that dmd, 
regardless whether it syntax checks unittests when they are 
disabled.
Mar 30 2017
parent deadalnix <deadalnix gmail.com> writes:
On Thursday, 30 March 2017 at 20:29:26 UTC, Dukc wrote:

 On Thursday, 30 March 2017 at 17:22:20 UTC, Stefan Koch wrote:

 SDC has the goal to be more principled.
 And Not to be Mr. fast and loose, right ?
 If a file parses it'd better be syntactically correct!
 All of it.


 Just an idea, but could the solution for SDC be to enable 
 unittests by default, disabling them would be explicit? That 
 would sure make using it alot more principled that dmd, 
 regardless whether it syntax checks unittests when they are 
 disabled.


SDC uses an utility called sdunit to JIT the unittest. Right now, 
sdunit doesn't handle exceptions so its utility is limited, but 
it's getting there.
Mar 31 2017
prev sibling next sibling parent reply XavierAP <n3minis-git yahoo.es> writes:
On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:

 Is that an acceptable tradeof ?


I would consider this harmful... The spec already states this 
about unit tests, so I'd guess the decision was taken in the past 
conscientiously.

If you're worried about compilation time, you can always define 
your unit tests in separate files that are included for 
compilation only when needed.
Mar 29 2017
parent reply ixid <adamsibson gmail.com> writes:
On Thursday, 30 March 2017 at 06:53:47 UTC, XavierAP wrote:

 On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:

 Is that an acceptable tradeof ?


 I would consider this harmful... The spec already states this 
 about unit tests, so I'd guess the decision was taken in the 
 past conscientiously.

 If you're worried about compilation time, you can always define 
 your unit tests in separate files that are included for 
 compilation only when needed.


Why is it harmful (actually asking, not telling you you're 
wrong)? I thought we were going to use a pay for what you use 
philosophy, if a unit test is not run then why is it paid for?
Mar 30 2017
next sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Thu, 30 Mar 2017 09:04:28 +0000, ixid wrote:


 Why is it harmful (actually asking, not telling you you're wrong)? I
 thought we were going to use a pay for what you use philosophy, if a
 unit test is not run then why is it paid for?


A person that doesn't run `dmd -unittest` (or `dub test`) prior to 
committing code could commit broken tests. In my mind if you write tests 
but don't run them, they're broken anyway.

--Ryan
Mar 30 2017
parent drug <drug2004 bk.ru> writes:
30.03.2017 14:47, rjframe пишет:

 On Thu, 30 Mar 2017 09:04:28 +0000, ixid wrote:


 Why is it harmful (actually asking, not telling you you're wrong)? I
 thought we were going to use a pay for what you use philosophy, if a
 unit test is not run then why is it paid for?


 A person that doesn't run `dmd -unittest` (or `dub test`) prior to
 committing code could commit broken tests. In my mind if you write tests
 but don't run them, they're broken anyway.

 --Ryan


Broken test could be parsable, but still broken. You need to run it to 
check if it is (not) broken anyway.
Mar 30 2017
prev sibling parent XavierAP <n3minis-git yahoo.es> writes:
On Thursday, 30 March 2017 at 09:04:28 UTC, ixid wrote:

 On Thursday, 30 March 2017 at 06:53:47 UTC, XavierAP wrote:

 I would consider this harmful... The spec already states this 
 about unit tests, so I'd guess the decision was taken in the 
 past conscientiously.

 If you're worried about compilation time, you can always 
 define your unit tests in separate files that are included for 
 compilation only when needed.


 Why is it harmful (actually asking, not telling you you're 
 wrong)? I thought we were going to use a pay for what you use 
 philosophy, if a unit test is not run then why is it paid for?


rjframe and Stefan have said it better than I could. I do 
understand the more I think about it how people could be worried 
about the downsides. Priorities depends on user cases and some 
personal inclination. But with the stated arguments I would think 
it's a bit of a slippery slope. And moreover for people so 
concerned with compilation time there are easy clean workarounds 
such as separate files. Compilers could implement something 
analogous to pre-compiled headers for this case.
Mar 30 2017
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
On 2017-03-29 13:16, deadalnix wrote:

 I was wondering. When uniitests aren't going to run, it may be desirable
 to skip parsing altogether, just lexing and counting braces until the
 matching closing brace is found.

 Obviously, this means that no error will be found in unittests blocks.
 That can contain pretty much anything that lex, so it's even more lax
 than what's allowed inside a static if.

 Is that an acceptable tradeof ?


I know Andrei has said he want to do this for as much as possible.

-- 
/Jacob Carlborg
Mar 31 2017
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/29/2017 4:16 AM, deadalnix wrote:

 I was wondering. When uniitests aren't going to run, it may be desirable to
skip
 parsing altogether, just lexing and counting braces until the matching closing
 brace is found.

 Obviously, this means that no error will be found in unittests blocks. That can
 contain pretty much anything that lex, so it's even more lax than what's
allowed
 inside a static if.

 Is that an acceptable tradeof ?



One of my longer term goals for DMD is to make it as lazy as possible - only 
parse and do semantic analysis if the result is actually needed. Not doing the 
parse for unused unittest blocks is a step in that direction.

The code is still required to be correct, but the compiler isn't required to 
diagnose it.
Mar 31 2017
parent reply Jonathan M Davis via Digitalmars-d <digitalmars-d puremagic.com> writes:
On Friday, March 31, 2017 17:49:48 Walter Bright via Digitalmars-d wrote:

 One of my longer term goals for DMD is to make it as lazy as possible -
 only parse and do semantic analysis if the result is actually needed. Not
 doing the parse for unused unittest blocks is a step in that direction.

 The code is still required to be correct, but the compiler isn't required
 to diagnose it.


There are certainly advantages to having the compiler skip over code where
it can, but it's pretty weird for the language to require that something be
valid and then have the compiler ignore it. That makes it really easy to
have something compile on one compiler but not another. Granted, properly
unit testing and testing code on a variety of platforms (so that all of the
version blocks and static if branches are tested) should catch those issues
regardless, but it does seem a bit off to me for the language to require
something and for the compiler to not care - especially the reference
compiler.

- Jonathan M Davis
Mar 31 2017
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/31/2017 6:33 PM, Jonathan M Davis via Digitalmars-d wrote:

 There are certainly advantages to having the compiler skip over code where
 it can, but it's pretty weird for the language to require that something be
 valid and then have the compiler ignore it. That makes it really easy to
 have something compile on one compiler but not another. Granted, properly
 unit testing and testing code on a variety of platforms (so that all of the
 version blocks and static if branches are tested) should catch those issues
 regardless, but it does seem a bit off to me for the language to require
 something and for the compiler to not care - especially the reference
 compiler.


I know. But it is worth it. It should enable D compilers to scale to handling 
very large imports.
Mar 31 2017
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Saturday, 1 April 2017 at 02:12:46 UTC, Walter Bright wrote:

 On 3/31/2017 6:33 PM, Jonathan M Davis via Digitalmars-d wrote:

 [...]


 I know. But it is worth it. It should enable D compilers to 
 scale to handling very large imports.


This should be optional and controlled via a switch like 
--fast-parse ?
Apr 01 2017
next sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 4/1/2017 12:39 AM, Stefan Koch wrote:

 This should be optional and controlled via a switch like --fast-parse ?


Too many switches are a disease, and we already have an awful lot.

The non-parsing of unittests have been there for quite a while now, and have
not 
caused any trouble. I see that as good evidence we're on a good path with this.
Apr 01 2017
parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Saturday, 1 April 2017 at 09:20:06 UTC, Walter Bright wrote:

 On 4/1/2017 12:39 AM, Stefan Koch wrote:

 This should be optional and controlled via a switch like 
 --fast-parse ?


 Too many switches are a disease, and we already have an awful 
 lot.

 The non-parsing of unittests have been there for quite a while 
 now, and have not caused any trouble. I see that as good 
 evidence we're on a good path with this.


Indeed. There's no need for such a switch as there is already one 
-unittest.
Apr 01 2017
prev sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Sat, 01 Apr 2017 07:39:49 +0000, Stefan Koch wrote:


 On Saturday, 1 April 2017 at 02:12:46 UTC, Walter Bright wrote:

 On 3/31/2017 6:33 PM, Jonathan M Davis via Digitalmars-d wrote:

 [...]


 I know. But it is worth it. It should enable D compilers to scale to
 handling very large imports.


 
 This should be optional and controlled via a switch like --fast-parse ?


I wonder if `dmd -o-` should continue to parse everything (possibly 
including unittests, which it currently doesn't do) rather than parse 
lazily. Though it would benefit from a speed increase, it's used to syntax 
check and would be more useful if it actually does parse everything.
Apr 01 2017
parent "H. S. Teoh via Digitalmars-d" <digitalmars-d puremagic.com> writes:
On Sat, Apr 01, 2017 at 02:14:25PM +0000, rjframe via Digitalmars-d wrote:

 On Sat, 01 Apr 2017 07:39:49 +0000, Stefan Koch wrote:
 

 On Saturday, 1 April 2017 at 02:12:46 UTC, Walter Bright wrote:

 On 3/31/2017 6:33 PM, Jonathan M Davis via Digitalmars-d wrote:

 [...]


 I know. But it is worth it. It should enable D compilers to scale
 to handling very large imports.


 
 This should be optional and controlled via a switch like
 --fast-parse ?


 
 I wonder if `dmd -o-` should continue to parse everything (possibly
 including unittests, which it currently doesn't do) rather than parse
 lazily. Though it would benefit from a speed increase, it's used to
 syntax check and would be more useful if it actually does parse
 everything.


What's wrong with `dmd -unittest -o-`?


T

-- 
Unix is my IDE. -- Justin Whear
Apr 01 2017