On 2016-02-29 17:27, Chris Wright wrote:
Simpler than that. Module foo.a imports std.stdio; module foo.b imports
foo.a and std.path. When compiling separately, you're not necessarily
changing the ordering property of the modules you run semantic on, but
you are changing the set of modules.
On Mon, 29 Feb 2016 08:22:45 +0100, Jacob Carlborg wrote:
> On 2016-02-28 22:03, Chris Wright wrote:
>
>> Or like there's a global counter that is incremented for each unittest.
>> A different order of traversal of unittests would result in a different
>> mangled name for the same unittest in
On 2016-02-28 22:03, Chris Wright wrote:
Or like there's a global counter that is incremented for each unittest. A
different order of traversal of unittests would result in a different
mangled name for the same unittest in different runs.
The question is why it would be different.
Here's a
On Sun, 28 Feb 2016 20:23:59 +0100, Jacob Carlborg wrote:
> On 2016-02-27 04:51, Walter Bright wrote:
>
>> It uses a sequence number to generate different ids for the unit tests.
>> In the former, it's the 531st unit test, the latter, the first.
>
> It sounds like the compiler is seeing
On 2016-02-27 04:51, Walter Bright wrote:
It uses a sequence number to generate different ids for the unit tests.
In the former, it's the 531st unit test, the latter, the first.
It sounds like the compiler is seeing different unit tests during the
different compilation. But why is that the
On Sunday, 28 February 2016 at 12:59:53 UTC, Atila Neves wrote:
On Saturday, 27 February 2016 at 11:31:53 UTC, Joakim wrote:
On Saturday, 27 February 2016 at 11:27:39 UTC, Walter Bright
wrote:
On 2/27/2016 1:12 AM, Atila Neves wrote:
I've had similar problems in the past with template mixins.
On Saturday, 27 February 2016 at 11:31:53 UTC, Joakim wrote:
On Saturday, 27 February 2016 at 11:27:39 UTC, Walter Bright
wrote:
On 2/27/2016 1:12 AM, Atila Neves wrote:
I've had similar problems in the past with template mixins.
It seems D's
compile-time features don't mix with any kind of
On Saturday, 27 February 2016 at 11:27:39 UTC, Walter Bright
wrote:
On 2/27/2016 1:12 AM, Atila Neves wrote:
I've had similar problems in the past with template mixins. It
seems D's
compile-time features don't mix with any kind of separate
compilation, which is
a shame.
Any ideas on how
On 2/27/2016 1:12 AM, Atila Neves wrote:
I've had similar problems in the past with template mixins. It seems D's
compile-time features don't mix with any kind of separate compilation, which is
a shame.
Any ideas on how unit tests should be named?
On Saturday, 27 February 2016 at 10:56:08 UTC, Atila Neves wrote:
On Saturday, 27 February 2016 at 10:18:53 UTC, Joakim wrote:
On Saturday, 27 February 2016 at 09:11:02 UTC, Atila Neves
wrote:
On Saturday, 27 February 2016 at 03:51:00 UTC, Walter Bright
wrote:
On 2/26/2016 4:45 AM, Atila
On 2/27/2016 1:11 AM, Atila Neves wrote:
On Saturday, 27 February 2016 at 03:51:00 UTC, Walter Bright wrote:
On 2/26/2016 4:45 AM, Atila Neves wrote:
'_D3bar16__unittestL2_531FZv'
'_D3bar14__unittestL2_1FZv'
It uses a sequence number to generate different ids for the unit tests. In the
On Saturday, 27 February 2016 at 10:18:53 UTC, Joakim wrote:
On Saturday, 27 February 2016 at 09:11:02 UTC, Atila Neves
wrote:
On Saturday, 27 February 2016 at 03:51:00 UTC, Walter Bright
wrote:
On 2/26/2016 4:45 AM, Atila Neves wrote:
'_D3bar16__unittestL2_531FZv'
'_D3bar14__unittestL2_1FZv'
On Saturday, 27 February 2016 at 09:11:02 UTC, Atila Neves wrote:
On Saturday, 27 February 2016 at 03:51:00 UTC, Walter Bright
wrote:
On 2/26/2016 4:45 AM, Atila Neves wrote:
'_D3bar16__unittestL2_531FZv'
'_D3bar14__unittestL2_1FZv'
It uses a sequence number to generate different ids for the
On Saturday, 27 February 2016 at 06:34:19 UTC, Joakim wrote:
On Friday, 26 February 2016 at 12:45:35 UTC, Atila Neves wrote:
foo.d:
-
void main() {
import bar;
foreach(ut; __traits(getUnitTests, bar)) ut();
}
-
bar.d:
-
unittest { assert(1 == 2); }
-
# compile all at
On Saturday, 27 February 2016 at 03:51:00 UTC, Walter Bright
wrote:
On 2/26/2016 4:45 AM, Atila Neves wrote:
'_D3bar16__unittestL2_531FZv'
'_D3bar14__unittestL2_1FZv'
It uses a sequence number to generate different ids for the
unit tests. In the former, it's the 531st unit test, the
latter,
On Friday, 26 February 2016 at 12:45:35 UTC, Atila Neves wrote:
foo.d:
-
void main() {
import bar;
foreach(ut; __traits(getUnitTests, bar)) ut();
}
-
bar.d:
-
unittest { assert(1 == 2); }
-
# compile all at once
dmd -unittest foo.d bar.d # fine
# compile separately
On 2/26/2016 4:45 AM, Atila Neves wrote:
'_D3bar16__unittestL2_531FZv'
'_D3bar14__unittestL2_1FZv'
It uses a sequence number to generate different ids for the unit tests. In the
former, it's the 531st unit test, the latter, the first.
On Friday, 26 February 2016 at 14:56:04 UTC, Jacob Carlborg wrote:
On 2016-02-26 13:45, Atila Neves wrote:
foo.d:
-
void main() {
import bar;
foreach(ut; __traits(getUnitTests, bar)) ut();
}
-
bar.d:
-
unittest { assert(1 == 2); }
-
# compile all at once
dmd
On 2016-02-26 13:45, Atila Neves wrote:
foo.d:
-
void main() {
import bar;
foreach(ut; __traits(getUnitTests, bar)) ut();
}
-
bar.d:
-
unittest { assert(1 == 2); }
-
# compile all at once
dmd -unittest foo.d bar.d # fine
# compile separately
dmd -c -unittest foo.d
foo.d:
-
void main() {
import bar;
foreach(ut; __traits(getUnitTests, bar)) ut();
}
-
bar.d:
-
unittest { assert(1 == 2); }
-
# compile all at once
dmd -unittest foo.d bar.d # fine
# compile separately
dmd -c -unittest foo.d
dmd -c -unittest bar.d
dmd foo.o bar.o
20 matches
Mail list logo
