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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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