[1]
Yesterday I tried to build a project with dub. dub had downloaded and installed dmd v2.065. The project and accompanying library had been built with dmd v2.064. dub said that the project was up to date and didn't need compiling. However, I got a long long error message informing me that there were undefined references (see below). I recompiled the library with dmd v2.065 and everything worked fine. Yet I wonder, is this behavior normal, i.e. dub says its alright but not really?

[2]
Another issue I encountered was when I recompiled the library, dmd 2.065 gave me an error that a goto statement skipped a variable. The case is as follows:

if (condition) {
  goto Label;
}

auto variable = getVariableValue(); // Only needed, if "condition" above not true
// do things with variable here (needed for what comes after "Label"

Label:
// Finish everything

I know that scope would be better and this is the only goto I have left. In order for the code to compile I had to move (as a quick fix)

auto variable = getVariableValue();

to before the if (condition) statement. Is this by design? If yes, why? Enlighten me, cos it shouldn't really matter, should it?

[3]
Last but not least, could [2] have triggered the error I got in [1]?

[Part of error message]
source/lib//libdlts.a(regex_770_e66.o): In function `_D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa':
/usr/include/dmd/phobos/std/regex.d:(.text._D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa+0x53): undefined reference to `_D3std5ascii6_ctypeyG128h'
/usr/include/dmd/phobos/std/regex.d:(.text._D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa+0x113): undefined reference to `_D3std5ascii6_ctypeyG128h'

Chris:

> [2]
> Another issue I encountered was when I recompiled the library, dmd 2.065 gave me an error that a goto statement skipped a variable. The case is as follows:
>
> if (condition) {
>   goto Label;
> }
>
> auto variable = getVariableValue(); // Only needed, if "condition" above not true
> // do things with variable here (needed for what comes after "Label"
>
> Label:
> // Finish everything
>
> I know that scope would be better and this is the only goto I have left. In order for the code to compile I had to move (as a quick fix)
>
> auto variable = getVariableValue();
>
> to before the if (condition) statement. Is this by design?

D specs state that gotos can't be used to skip a variable definition. In the last compiler version this rule has being implemented and enforced. So the original code was not D-conformant.

Bye,
bearophile

On Friday, 14 March 2014 at 10:49:57 UTC, bearophile wrote:
> Chris:
>
>> [2]
>> Another issue I encountered was when I recompiled the library, dmd 2.065 gave me an error that a goto statement skipped a variable. The case is as follows:
>>
>> if (condition) {
>>  goto Label;
>> }
>>
>> auto variable = getVariableValue(); // Only needed, if "condition" above not true
>> // do things with variable here (needed for what comes after "Label"
>>
>> Label:
>> // Finish everything
>>
>> I know that scope would be better and this is the only goto I have left. In order for the code to compile I had to move (as a quick fix)
>>
>> auto variable = getVariableValue();
>>
>> to before the if (condition) statement. Is this by design?
>
> D specs state that gotos can't be used to skip a variable definition. In the last compiler version this rule has being implemented and enforced. So the original code was not D-conformant.
>
> Bye,
> bearophile

Thanks for the answer. Any particular reason why the variable declaration should not be skipped? Security? Code generation?

Chris:

> Thanks for the answer. Any particular reason why the variable declaration should not be skipped? Security? Code generation?

In D all variables get initialized at the definition point (unless you add a "= void"). A goto skips this initialization, and this breaks certain safety generates D relies on.

Bye,
bearophile

> In D all variables get initialized at the definition point (unless you add a "= void"). A goto skips this initialization, and this breaks certain safety generates D relies on.

Look for @safe functions:

void main() @safe {
    int* p = void;
}


test.d(2,10): Error: variable test.main.p void initializers for pointers not allowed in safe functions

Bye,
bearophile

On Friday, 14 March 2014 at 11:14:15 UTC, bearophile wrote:
> Chris:
>
>> Thanks for the answer. Any particular reason why the variable declaration should not be skipped? Security? Code generation?
>
> In D all variables get initialized at the definition point (unless you add a "= void"). A goto skips this initialization, and this breaks certain safety generates D relies on.
>
> Bye,
> bearophile

Interesting, though, that I got away with it until v2.065.

On Friday, 14 March 2014 at 11:41:49 UTC, Chris wrote:
> Interesting, though, that I got away with it until v2.065.

DMD still has quite a lot of "accepts-invalid" bugs.

On 3/14/2014 7:43 PM, Chris wrote:
> [1]
> Yesterday I tried to build a project with dub. dub had downloaded and
> installed dmd v2.065. The project and accompanying library had been

I'm curious what you mean by this. I don't see any way to get DMD through dub.

> built with dmd v2.064. dub said that the project was up to date and
> didn't need compiling. However, I got a long long error message
> informing me that there were undefined references (see below). I
> recompiled the library with dmd v2.065 and everything worked fine. Yet I
> wonder, is this behavior normal, i.e. dub says its alright but not really?

This is normal. dub doesn't have any idea which version of which compiler a set of binary files was built with. What it does is to compare the times of the binaries with those of the source modules to determine if anything has changed. If not, it doesn't build. This is essentially how most build tools behave, no matter which language you're working with.

Of course, it would be possible to implement the tracking of compiler versions. The only way I can see to do that off the top of my head is that dub would have to maintain a registry that logs the compiler version used on the last compile for each binary, then parse the output of 'dmd' or 'dmd --help' to find the version number (and do that for each supported compiler) of the compiler currently in use. But it would have to do that at the beginning of every compile. In my mind, the cost greatly outweighs the benefit.

Just 'dub build --force' when you upgrade your compiler.

On 3/14/2014 7:43 PM, Chris wrote:

>
> [3]
> Last but not least, could [2] have triggered the error I got in [1]?
>
> [Part of error message]
> source/lib//libdlts.a(regex_770_e66.o): In function
> `_D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa':
>
> /usr/include/dmd/phobos/std/regex.d:(.text._D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa+0x53):
> undefined reference to `_D3std5ascii6_ctypeyG128h'
> /usr/include/dmd/phobos/std/regex.d:(.text._D3std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv245__T4findS2283std5regex102__T10replaceFmtTAxaTS3std5regex19__T8CapturesTAyaTmZ8CapturesTS3std5array17__T8AppenderTAyaZ8AppenderZ10replaceFmtFNaNfAxaS3std5regex19__T8CapturesTAyaTmZ8CapturesS3std5array17__T8AppenderTAyaZ8AppenderbZv9__lambda7TAxaZ4findMFNaNfAxaZAxa+0x113):
> undefined reference to `_D3std5ascii6_ctypeyG128h'

Apparently, dub determined that even though no compilation needed to take place, linking was needed and it ran the link step. These errors are most likely because of the version mismatch between the project's object files (built against 2.064 Phobos) and the 2.065 Phobos archive.

On Friday, 14 March 2014 at 14:11:45 UTC, Mike Parker wrote:
> On 3/14/2014 7:43 PM, Chris wrote:
>> [1]
>> Yesterday I tried to build a project with dub. dub had downloaded and
>> installed dmd v2.065. The project and accompanying library had been
>
> I'm curious what you mean by this. I don't see any way to get DMD through dub.
>

I wasn't exact, when I downloaded dub, I was asked to download dmd, I downloaded the latest version.

>> built with dmd v2.064. dub said that the project was up to date and
>> didn't need compiling. However, I got a long long error message
>> informing me that there were undefined references (see below). I
>> recompiled the library with dmd v2.065 and everything worked fine. Yet I
>> wonder, is this behavior normal, i.e. dub says its alright but not really?
>
> This is normal. dub doesn't have any idea which version of which compiler a set of binary files was built with. What it does is to compare the times of the binaries with those of the source modules to determine if anything has changed. If not, it doesn't build. This is essentially how most build tools behave, no matter which language you're working with.

> Of course, it would be possible to implement the tracking of compiler versions. The only way I can see to do that off the top of my head is that dub would have to maintain a registry that logs the compiler version used on the last compile for each binary, then parse the output of 'dmd' or 'dmd --help' to find the version number (and do that for each supported compiler) of the compiler currently in use. But it would have to do that at the beginning of every compile. In my mind, the cost greatly outweighs the benefit.
>
> Just 'dub build --force' when you upgrade your compiler.