On Thursday, 3 November 2016 at 12:17:29 UTC, Sönke Ludwig wrote:
> Am 03.11.2016 um 06:58 schrieb Andre Pany:
>
> Temp-folder builds are only done if the special shebang invocation syntax is used (i.e. "dub file.d <program args"). Building with "dub --single file.d" should build normally. This was the case within the thread, too. Has anything changed since then?

Unfortunately yes, the behavior of dub included in dmd 2.072 is not as expected (windows & linux).

/+ dub.sdl:
	name "app"
+/
void main(){}

dub --single app.d
>> Running ..\..\..\..\..\Users\abcdef\AppData\Local\Temp\.dub\build\app-~master\application-debug-windows-x86-dmd_2072-A4FA96FDE8C9353FB025486E4835F2E0\app.exe

Same behavior for dub build --single app.d

Kind regards
André

On 11/2/16 8:36 AM, Johan Engelen wrote:
> On Tuesday, 1 November 2016 at 16:40:42 UTC, Andrei Alexandrescu wrote:
>> On 11/01/2016 11:41 AM, Johan Engelen wrote:
>>> On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
>>>> Glad to announce D 2.072.0.
>>>
>>> DMD 2.072.0 miscompiles/uncovers a bug in LDC, so I switched back to DMD
>>> 2.071.2 for CI testing. :(
>>
>> Is there somebody working on that bug? Thanks. -- Andrei
>
> LDC built with DMD 2.072.0 gives the following error when run:
> object.Error@src/rt/minfo.d(356): Cyclic dependency between module
> ddmd.traits and ddmd.cond
> ddmd.traits* ->
> ddmd.attrib ->
> ddmd.cond* ->
> ddmd.expression ->
> ddmd.traits*

The issue is that DDMD has cycles, always has. But the cycle detection was broken. This is now fixed in 2.072. An unfortunate side effect from having broken cycle detection since 2011 is that many projects will now detect cycles. 2.072 is going to break a lot of code that was already "broken". I use scare quotes because likely the code is just fine, but the cycle detection is so broad that it's easy to get caught in the net.

The best answer is to somehow do better cycle detection (e.g. determine if there really are dependencies that break with cycles). We have some ideas, but nothing has been fleshed out yet.

-Steve

On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote:
> On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote:
>>
>> I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot since master straping works there's probably something that's been fixed in one or two of these ddmd modules, likely a static ctor...
>
> Maybe after this:
>
> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368
>
> ddmd.attribs was removed
>
> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15
>
> and it was also part of the cycle.

Thanks for the detective work.
I wonder where the bug is: in 2.071 or in 2.072 :)

On 10/31/2016 03:27 AM, Martin Nowak wrote:
> Glad to announce D 2.072.0.

NB: Current release notes are outdated and wrong about `-transition=safe` flag. It was completely repurposed in stable branch (https://github.com/dlang/dmd/pull/6183) but somehow changes to release notes there do not propagate to released changelog.

On 11/3/16 10:49 AM, Johan Engelen wrote:
> On Wednesday, 2 November 2016 at 15:13:43 UTC, anonymous wrote:
>> On Wednesday, 2 November 2016 at 15:08:26 UTC, anonymous wrote:
>>>
>>> I confirm, dmd 2.072 can't build dmd 2.071.2, same error, but boot
>>> since master straping works there's probably something that's been
>>> fixed in one or two of these ddmd modules, likely a static ctor...
>>
>> Maybe after this:
>>
>> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368
>>
>>
>> ddmd.attribs was removed
>>
>> https://github.com/dlang/dmd/commit/1d0ab8b9c136e46bf449c506ca25d2c8a784f7b9#diff-b4674e7b5d3a44178526afdefc9aa368L15
>>
>>
>> and it was also part of the cycle.
>
> Thanks for the detective work.
> I wonder where the bug is: in 2.071 or in 2.072 :)

Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items.

Note that the push to remove imports to packages and instead import more specific submodules (i.e. import std.range.primitives instead of std.range) also plays a factor (it's how I discovered the cycles were broken). I doubt there was much of that in dmd front end.

-Steve

On Thursday, 3 November 2016 at 15:51:22 UTC, Steven Schveighoffer wrote:
>
> Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items.

My question is: any cycle is invalid?

-Johan

On Friday, 4 November 2016 at 00:42:48 UTC, Johan Engelen wrote:
> On Thursday, 3 November 2016 at 15:51:22 UTC, Steven Schveighoffer wrote:
>>
>> Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items.
>
> My question is: any cycle is invalid?

nevermind, I found this:
https://dlang.org/spec/module.html#order_of_static_ctor

On Monday, 31 October 2016 at 01:27:08 UTC, Martin Nowak wrote:
> Glad to announce D 2.072.0.
>
> http://dlang.org/changelog/2.072.0.html
>
> -Martin

I've run into a problem with code using ctRegex that fails to compile only in release build.

private immutable string TOC_LINE_PATTERN = `#{1,}\s*(?P<key>.*):\s*(?P<value>.*)`;

auto linePattern = ctRegex!(TOC_LINE_PATTERN);

Error:

/usr/include/dmd/phobos/std/uni.d(3133,13): Error: integral constant must be scalar type, not void
/usr/include/dmd/phobos/std/functional.d-mixin-200(200,1): Error: __a.data is not yet implemented at compile time
/usr/include/dmd/phobos/std/algorithm/searching.d(894,34):        called from here: pred2(((InversionList!(GcPolicy) __copytmp4412 = (ref InversionList!(GcPolicy) this = __copytmp4412 = haystack[cast(ulong)i];) , ((ref CowArray!(GcPolicy) this = this.data;) , !((ref CowArray!(GcPolicy) this = this;) , this.data.length == 0LU) && ((ref CowArray!(GcPolicy) this = this;) , ((uint cnt = ((ref CowArray!(GcPolicy) this = this;) , this.data[__dollar - 1LU]) + 1u;)) , this.data[__dollar - 1LU] = cnt));) , __copytmp4412))
/usr/include/dmd/phobos/std/algorithm/searching.d(816,28):        called from here: countUntil(haystack)
/usr/include/dmd/phobos/std/regex/internal/parser.d(327,46):        called from here: countUntil(this.charsets, ((InversionList!(GcPolicy) __copytmp4413 = (__copytmp4413 = set).__fieldPostblit();) , __copytmp4413))
/usr/include/dmd/phobos/std/regex/internal/parser.d(946,30):        called from here: this.g.charsetToIr(set.add(10u, 11u).add(13u, 14u).inverted())
/usr/include/dmd/phobos/std/regex/internal/parser.d(858,26):        called from here: this.parseAtom()
/usr/include/dmd/phobos/std/regex/internal/parser.d(636,23):        called from here: this.parseRegex()
/usr/include/dmd/phobos/std/regex/package.d(378,61):        called from here: parser.this(pattern, flags)
/usr/include/dmd/phobos/std/regex/package.d(349,25):        called from here: regexImpl(pat, flags)
/usr/include/dmd/phobos/std/regex/package.d(357,17):        called from here: regex([pattern], flags)
/usr/include/dmd/phobos/std/regex/package.d(387,19):        called from here: regex(TOC_LINE_PATTERN, [])
/usr/include/dmd/phobos/std/regex/package.d(409,54): Error: template instance luaaddon.tocparser.TocParser.ctRegexImpl!(TOC_LINE_PATTERN, []) error instantiating
../libs/luaaddon/source/luaaddon/tocparser.d(31,22):        instantiated from here: ctRegex!(TOC_LINE_PATTERN, [])

It compiles just fine in debug build.

Thanks!

On Monday, 31 October 2016 at 20:35:24 UTC, Martin Nowak wrote:
> and I did take care of that forward reference bug (Issue 16607).

Thanks again for that. That one would've actually kept me from upgrading for my current project.

On Friday, November 04, 2016 00:45:18 Johan Engelen via Digitalmars-d- announce wrote:
> On Friday, 4 November 2016 at 00:42:48 UTC, Johan Engelen wrote:
> > On Thursday, 3 November 2016 at 15:51:22 UTC, Steven
> >
> > Schveighoffer wrote:
> >> Any cycles that are "newly discovered" were already there. What was happening is that the runtime did not detect the cycle, and was arbitrarily choosing an order for initializing these modules. Either a) the arbitrary order happened to be right, or b) the order didn't matter. Most of the time it's b, because most static ctors don't depend on externally initialized items.
> >
> > My question is: any cycle is invalid?
>
> nevermind, I found this: https://dlang.org/spec/module.html#order_of_static_ctor

Yeah, that's why we avoid static constructors in Phobos if we can. In theory, they're great, but in practice, they have a tendency to cause problems. Modules which don't import much of anything else from within the same library tend to be fine, but once a library or application has modules which import other modules within that library, you can get circular imports surprisingly easily, and Phobos is rife with them. There are cases where we actually have other modules specifically to do the static constructors for another module in order to avoid having static constructors in the import cycle (e.g. std.stdiobase does that for std.stdio) - but that doesn't play well with stuff like immutable, just mutable stuff that needs to be initialized at runtime.

- Jonathan M Davis