Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
On Sat, Apr 01, 2017 at 02:14:25PM +, rjframe via Digitalmars-d wrote: > On Sat, 01 Apr 2017 07:39:49 +, 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
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
On Sat, 01 Apr 2017 07:39:49 +, 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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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 ?
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
30.03.2017 14:47, rjframe пишет: On Thu, 30 Mar 2017 09:04:28 +, 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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
On Thu, 30 Mar 2017 09:04:28 +, 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
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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?
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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!
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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!
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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.
Re: Is it acceptable to not parse unittest blocks when unittests are disabled ?
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_() {
...
}
}
Which is basically what you said.
Is it acceptable to not parse unittest blocks when unittests are disabled ?
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 ?
