March 30, 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:
>> 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.
March 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
March 30, 2017
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.
March 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.

March 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:
>> 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.
March 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:
>>
>> 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.
March 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.


March 31, 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
March 31, 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 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.

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