digitalmars.D - Is it acceptable to not parse unittest blocks when unittests are
- deadalnix (7/7) Mar 29 2017 I was wondering. When uniitests aren't going to run, it may be
- rikki cattermole (8/15) Mar 29 2017 I see no reason to not to treat it as:
- deadalnix (4/5) Mar 29 2017 It isn't. version needs to be parsed and thus, grammatically
- rikki cattermole (3/6) Mar 29 2017 Hmm, well that is another thing that could be disabled to shave some
- Stefan Koch (5/12) Mar 29 2017 I would not do this trade off,
- Vladimir Panteleev (16/19) Mar 29 2017 Sorry, is this not already the case?
- Stefan Koch (3/22) Mar 29 2017 Surprise!
- Vladimir Panteleev (3/8) Mar 29 2017 https://github.com/dlang/dmd/pull/4704
- Claude (6/15) Mar 30 2017 To quote Walter Bright from that PR, unittest can contain invalid
- deadalnix (4/19) Mar 30 2017 Alright then, it looks like it is :)
- Stefan Koch (5/27) Mar 30 2017 SDC has the goal to be more principled.
- XavierAP (7/8) Mar 29 2017 I would consider this harmful... The spec already states this
- ixid (4/13) Mar 30 2017 Why is it harmful (actually asking, not telling you you're
- Jacob Carlborg (4/11) Mar 31 2017 I know Andrei has said he want to do this for as much as possible.
- Walter Bright (6/13) Mar 31 2017 One of my longer term goals for DMD is to make it as lazy as possible - ...
- Jonathan M Davis via Digitalmars-d (11/16) Mar 31 2017 There are certainly advantages to having the compiler skip over code whe...
- Walter Bright (3/12) Mar 31 2017 I know. But it is worth it. It should enable D compilers to scale to han...
- Stefan Koch (3/7) Apr 01 2017 This should be optional and controlled via a switch like
- Walter Bright (4/5) Apr 01 2017 Too many switches are a disease, and we already have an awful lot.
- Patrick Schluter (3/11) Apr 01 2017 Indeed. There's no need for such a switch as there is already one
- rjframe (5/13) Apr 01 2017 I wonder if `dmd -o-` should continue to parse everything (possibly
- H. S. Teoh via Digitalmars-d (5/22) Apr 01 2017 What's wrong with `dmd -unittest -o-`?
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
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
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
On 29/03/2017 1:16 PM, deadalnix wrote:On Wednesday, 29 March 2017 at 11:22:59 UTC, rikki cattermole wrote:Hmm, well that is another thing that could be disabled to shave some time off the build times I suppose.Which is basically what you said.It isn't. version needs to be parsed and thus, grammatically valid.
Mar 29 2017
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
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
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:Surprise!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
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:https://github.com/dlang/dmd/pull/4704I 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?
Mar 29 2017
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: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.On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix wrote:https://github.com/dlang/dmd/pull/4704I 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?
Mar 30 2017
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
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: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.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
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
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 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.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 31 2017
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
On Thursday, 30 March 2017 at 06:53:47 UTC, XavierAP wrote:On Wednesday, 29 March 2017 at 11:16:28 UTC, deadalnix 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?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 30 2017
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
30.03.2017 14:47, rjframe пишет:On Thu, 30 Mar 2017 09:04:28 +0000, ixid wrote:Broken test could be parsable, but still broken. You need to run it to check if it is (not) broken anyway.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
On Thursday, 30 March 2017 at 09:04:28 UTC, ixid wrote:On Thursday, 30 March 2017 at 06:53:47 UTC, XavierAP wrote: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.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
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
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
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
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
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:This should be optional and controlled via a switch like --fast-parse ?[...]I know. But it is worth it. It should enable D compilers to scale to handling very large imports.
Apr 01 2017
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
On Saturday, 1 April 2017 at 09:20:06 UTC, Walter Bright wrote:On 4/1/2017 12:39 AM, Stefan Koch wrote:Indeed. There's no need for such a switch as there is already one -unittest.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
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: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.On 3/31/2017 6:33 PM, Jonathan M Davis via Digitalmars-d wrote:This should be optional and controlled via a switch like --fast-parse ?[...]I know. But it is worth it. It should enable D compilers to scale to handling very large imports.
Apr 01 2017
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:What's wrong with `dmd -unittest -o-`? T -- Unix is my IDE. -- Justin WhearOn Saturday, 1 April 2017 at 02:12:46 UTC, Walter Bright wrote: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.On 3/31/2017 6:33 PM, Jonathan M Davis via Digitalmars-d wrote:This should be optional and controlled via a switch like --fast-parse ?[...]I know. But it is worth it. It should enable D compilers to scale to handling very large imports.
Apr 01 2017