On 2017-03-25 08:25, Uranuz wrote:

> ../ivy/src/ivy/interpreter.d-mixin-670(670): Error: undefined identifier
> '__cmp' in module 'object'

I think this error is due to a mismatch of DMD and druntime. The compiler lowers some kind of comparison to a call to __cmp which is implemented in the "object" module in druntime. This is a quite recent change.

-- 
/Jacob Carlborg

On 2017-03-25 09:13, Uranuz wrote:

> I just put debug messages on every `assert` and figured out it fails on
> lines:
>                     bool implicit0 = (f.next.ty == Tvoid && isMain());
>                     Type tret = implicit0 ? Type.tint32 : f.next;
>                     assert(tret.ty != Tvoid);
>                     if (vresult || returnLabel)
>                         buildResultVar(scout ? scout : sc2, tret);
> I really don't understand what it is... Now I cannot share codebase
> easily. Seems that it fails on my programme `main` function or near
> that, because compiler stack not so deep. There is some check for isMain
> AFAIK... What is this about?

To me it looks like there's some mismatch of the declared return type of "main" and what is actually returned. In D it's possible to declare "main" to return "void" and the compiler/runtime will automatically handle and infer the exit code of the program. Can you show just the "main" function?

-- 
/Jacob Carlborg

On Saturday, 25 March 2017 at 13:34:43 UTC, Uranuz wrote:
> On Saturday, 25 March 2017 at 07:57:11 UTC, Stefan Koch wrote:
>> [...]
>
> If you wish to help. You are welcome) I created branch in my repository `https://github.com/uranuz/ivy` called `v0.1/fail_on_compiler_error`. Seems that error depends on the order of source files that were passed to DMD. The way that error occurs is using RDMD utility, by running command(in project root folder):
> rdmd "-Isrc/" -ofsimple_run_test test/simple_run_test.d
>
> [...]

I can reproduce this.
The function which fails is:
DirAttrsBlock.this(DirAttrKind attrKind, DirValueAttr!true[string] attrs)

On Saturday, 25 March 2017 at 17:31:33 UTC, Stefan Koch wrote:
> On Saturday, 25 March 2017 at 13:34:43 UTC, Uranuz wrote:
>> On Saturday, 25 March 2017 at 07:57:11 UTC, Stefan Koch wrote:
>>> [...]
>>
>> If you wish to help. You are welcome) I created branch in my repository `https://github.com/uranuz/ivy` called `v0.1/fail_on_compiler_error`. Seems that error depends on the order of source files that were passed to DMD. The way that error occurs is using RDMD utility, by running command(in project root folder):
>> rdmd "-Isrc/" -ofsimple_run_test test/simple_run_test.d
>>
>> [...]
>
> I can reproduce this.
> The function which fails is:
> DirAttrsBlock.this(DirAttrKind attrKind, DirValueAttr!true[string] attrs)

Yes. I fugured out that it fails on this line too. But I don't understand why. Compiler fails on assert and doesn't give any meaningful info about reasons. In release version of compiler it's just segfault. And I don't understand why changing order of source files passed to DMD makes it working... I'm not enough good in knowlege of compiler internals, so it's surprise for me...

On Saturday, 25 March 2017 at 17:41:49 UTC, Uranuz wrote:
> On Saturday, 25 March 2017 at 17:31:33 UTC, Stefan Koch wrote:
>> On Saturday, 25 March 2017 at 13:34:43 UTC, Uranuz wrote:
>>> On Saturday, 25 March 2017 at 07:57:11 UTC, Stefan Koch wrote:
>>>> [...]
>>>
>>> If you wish to help. You are welcome) I created branch in my repository `https://github.com/uranuz/ivy` called `v0.1/fail_on_compiler_error`. Seems that error depends on the order of source files that were passed to DMD. The way that error occurs is using RDMD utility, by running command(in project root folder):
>>> rdmd "-Isrc/" -ofsimple_run_test test/simple_run_test.d
>>>
>>> [...]
>>
>> I can reproduce this.
>> The function which fails is:
>> DirAttrsBlock.this(DirAttrKind attrKind, DirValueAttr!true[string] attrs)
>
> Yes. I fugured out that it fails on this line too. But I don't understand why. Compiler fails on assert and doesn't give any meaningful info about reasons. In release version of compiler it's just segfault. And I don't understand why changing order of source files passed to DMD makes it working... I'm not enough good in knowlege of compiler internals, so it's surprise for me...

It might be that a the particular template does not get instantiated if the order is different.
The assert triggers because the constructor is indeed a function which returns void.
But at this stage it is not expected to return void.
This is indicative of a compiler bug.

On Saturday, 25 March 2017 at 17:47:18 UTC, Stefan Koch wrote:
> On Saturday, 25 March 2017 at 17:41:49 UTC, Uranuz wrote:
>> On Saturday, 25 March 2017 at 17:31:33 UTC, Stefan Koch wrote:
>>> On Saturday, 25 March 2017 at 13:34:43 UTC, Uranuz wrote:
>>>> [...]
>>>
>>> I can reproduce this.
>>> The function which fails is:
>>> DirAttrsBlock.this(DirAttrKind attrKind, DirValueAttr!true[string] attrs)
>>
>> Yes. I fugured out that it fails on this line too. But I don't understand why. Compiler fails on assert and doesn't give any meaningful info about reasons. In release version of compiler it's just segfault. And I don't understand why changing order of source files passed to DMD makes it working... I'm not enough good in knowlege of compiler internals, so it's surprise for me...
>
> It might be that a the particular template does not get instantiated if the order is different.
> The assert triggers because the constructor is indeed a function which returns void.
> But at this stage it is not expected to return void.
> This is indicative of a compiler bug.

What is a good practice to make a bug report if I can't give some reduced case when problem occurs? Is it normal to just put link to my repo and branch with this problem and put instruction how to repeat this bug?

On Saturday, 25 March 2017 at 18:10:30 UTC, Uranuz wrote:
>
> What is a good practice to make a bug report if I can't give some reduced case when problem occurs? Is it normal to just put link to my repo and branch with this problem and put instruction how to repeat this bug?

It is very important to reduce these bugs.
Since we compiler devs like to focus on the problem rather then figureing out a certain build process.
I am going to reduce this now.

On Saturday, 25 March 2017 at 18:19:34 UTC, Stefan Koch wrote:
> On Saturday, 25 March 2017 at 18:10:30 UTC, Uranuz wrote:
>>
>> What is a good practice to make a bug report if I can't give some reduced case when problem occurs? Is it normal to just put link to my repo and branch with this problem and put instruction how to repeat this bug?
>
> It is very important to reduce these bugs.
> Since we compiler devs like to focus on the problem rather then figureing out a certain build process.
> I am going to reduce this now.

Thanks for this) I found more interesting info. In file src/ivy/common.d I put local imports:
import ivy.compiler: IDirectiveCompiler;
import ivy.interpreter: INativeDirectiveInterpreter;
...into global scope. And now it says that it conflicts with symbols from the place it was imported from. Maybe these problemes are connected somehow... or I'm doing something completely wrong)

uranuz@freelancer:~/sources/ivy$ rdmd "-Isrc/" -ofsimple_run_test test/simple_run_test.d
src/ivy/common.d(13): Error: undefined identifier 'INativeDirectiveInterpreter'
src/ivy/interpreter.d(247): Error: ivy.common.INativeDirectiveInterpreter at src/ivy/common.d(13) conflicts with ivy.interpreter_data.INativeDirectiveInterpreter at src/ivy/interpreter_data.d(336)
src/ivy/interpreter.d(249): Error: function ivy.interpreter.RenderDirInterpreter.interpret does not override any function
src/ivy/interpreter.d(271): Error: function ivy.interpreter.RenderDirInterpreter.attrBlocks does not override any function
src/ivy/common.d(13): Error: ivy.common.INativeDirectiveInterpreter at src/ivy/common.d(13) conflicts with ivy.interpreter_data.INativeDirectiveInterpreter at src/ivy/interpreter_data.d(336)
Failed: ["dmd", "-Isrc/", "-v", "-o-", "test/simple_run_test.d", "-Itest"]

On Saturday, 25 March 2017 at 18:19:34 UTC, Stefan Koch wrote:
>
> It is very important to reduce these bugs.
> Since we compiler devs like to focus on the problem rather then figureing out a certain build process.
> I am going to reduce this now.

This seems to be related to an import circle.
a template in interpreter_data.d needs node.d
node.d needs common.d
a struct declaration in common.d needs interpreter_data.d