On 11/03/2016 05:51 PM, Steven Schveighoffer wrote:
> 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.

It does not justify immediate breaking change. What should have been done instead:

- Keep old behavior by default by default but print non-fatal runtime
message that cycles are detected.
- Provide options both to make cycle detection fatal and to suppress
message completely.
- Make fatal one the default one release later

I presume I have to look for commits that implement http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this?

On 11/10/16 8:26 AM, Dicebot wrote:
> On 11/03/2016 05:51 PM, Steven Schveighoffer wrote:
>> 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.
>
> It does not justify immediate breaking change.

> What should have been
> done instead:
>
> - Keep old behavior by default by default but print non-fatal runtime
> message that cycles are detected.

This is not possible. Old behavior DID detect some cycles. The new algorithm detects ALL cycles, and handles them all in the same way. What you are asking is for cycles detected by old algorithm to fail, but ones that wouldn't have been detected to pass. Not to mention that the order of ctor execution is not guaranteed to be the same (i.e. some latent bug may be hiding there).

Only possibility is just to ignore ALL cycles, and print them if any are detected.

> I presume I have to look for commits that implement
> http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this?

The PR for this was here: https://github.com/dlang/druntime/pull/1668

-Steve

On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote:
> This is not possible. Old behavior DID detect some cycles. The new algorithm detects ALL cycles, and handles them all in the same way. What you are asking is for cycles detected by old algorithm to fail, but ones that wouldn't have been detected to pass. Not to mention that the order of ctor execution is not guaranteed to be the same (i.e. some latent bug may be hiding there).
>
> Only possibility is just to ignore ALL cycles, and print them if any are detected.
>
>> I presume I have to look for commits that implement
>> http://dlang.org/changelog/2.072.0.html#drt-oncycle to fixup this?
>
> The PR for this was here: https://github.com/dlang/druntime/pull/1668


Thanks! I'll have to check the code first :)

On 11/05/2016 06:04 AM, Soulsbane wrote:
> 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.

Can't reproduce:

$ cat sample.d
unittest
{
    import std.regex;
    static immutable TOC_LINE_PATTERN =
`#{1,}\s*(?P<key>.*):\s*(?P<value>.*)`;
    auto linePattern = ctRegex!(TOC_LINE_PATTERN);
}

$ dmd-dev -release -O -inline -unittest -main -run sample.d

Can you provide more details?

On Thursday, 10 November 2016 at 15:38:08 UTC, Dicebot wrote:
> On 11/05/2016 06:04 AM, Soulsbane wrote:
>> 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.
>
> Can't reproduce:
>
> $ cat sample.d
> unittest
> {
>     import std.regex;
>     static immutable TOC_LINE_PATTERN =
> `#{1,}\s*(?P<key>.*):\s*(?P<value>.*)`;
>     auto linePattern = ctRegex!(TOC_LINE_PATTERN);
> }
>
> $ dmd-dev -release -O -inline -unittest -main -run sample.d
>
> Can you provide more details?

Sorry I hadn't gotten back on this. Isolating the code like you did doesn't produce the error. It only fails in my larger project(same code). It's strange.

The code is in https://github.com/Soulsbane/luaaddon/blob/master/source/luaaddon/tocparser.d

Using struct TocParser in an empty project(just main) works just fine. But as part of my later project(skeletor) it fails to compile.

Thanks.

On Thursday, 10 November 2016 at 23:02:09 UTC, Soulsbane wrote:
> On Thursday, 10 November 2016 at 15:38:08 UTC, Dicebot wrote:
>> On 11/05/2016 06:04 AM, Soulsbane wrote:
>>> [...]
>>
>> Can't reproduce:
>>
>> $ cat sample.d
>> unittest
>> {
>>     import std.regex;
>>     static immutable TOC_LINE_PATTERN =
>> `#{1,}\s*(?P<key>.*):\s*(?P<value>.*)`;
>>     auto linePattern = ctRegex!(TOC_LINE_PATTERN);
>> }
>>
>> $ dmd-dev -release -O -inline -unittest -main -run sample.d
>>
>> Can you provide more details?
>
> Sorry I hadn't gotten back on this. Isolating the code like you did doesn't produce the error. It only fails in my larger project(same code). It's strange.
>
> The code is in https://github.com/Soulsbane/luaaddon/blob/master/source/luaaddon/tocparser.d
>
> Using struct TocParser in an empty project(just main) works just fine. But as part of my later project(skeletor) it fails to compile.
>
> Thanks.

Linked wrong file. https://github.com/Soulsbane/luaaddon/blob/7d60711b7b733144f3925a57380e58eb2aab997e/source/luaaddon/tocparser.d is the correct one.

On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote:
> Only possibility is just to ignore ALL cycles, and print them if any are detected.

Run the new detector and if it fails, run the old one, if it succeeds, print a message.

On 11/11/2016 04:54 AM, Kagamin wrote:
> On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer wrote:
>> Only possibility is just to ignore ALL cycles, and print them if any
>> are detected.
>
> Run the new detector and if it fails, run the old one, if it succeeds,
> print a message.

Or:

Run the new dmd. If it fails, either fix your code or go temporarily go back to the old dmd until you can fix your code.

On Friday, 11 November 2016 at 13:21:40 UTC, Nick Sabalausky wrote:
> Run the new dmd. If it fails, either fix your code or go temporarily go back to the old dmd until you can fix your code.

D will never be considered production ready as pong as this attiude remaind. Your described scenario in practice works like this:

- You decide to delay fix until you have time to investigate
- Half of users of your library you (or your colleagues) complain that they can't upgrade their projects because you areso slow
- You desperately find time to do required fix which proves bavkwards incompatible
- Now the other half of your users (colleagues) complain that your rush to upgrade forces them to switch to immature compiler

.. or one can spend one extra hour to implement deprecation path and the issue disappears completely.

On 11/11/16 8:21 AM, Nick Sabalausky wrote:
> On 11/11/2016 04:54 AM, Kagamin wrote:
>> On Thursday, 10 November 2016 at 13:58:56 UTC, Steven Schveighoffer
>> wrote:
>>> Only possibility is just to ignore ALL cycles, and print them if any
>>> are detected.
>>
>> Run the new detector and if it fails, run the old one, if it succeeds,
>> print a message.
>
> Or:
>
> Run the new dmd. If it fails, either fix your code or go temporarily go
> back to the old dmd until you can fix your code.
>

The option to ignore the cycles is there, added to allow for people to use the new DMD even if cycles exist. However, it is a runtime switch, which means you have to run it that way.

-Steve