• Bauss (24/24) Apr 17 2016 Can there please be implemented something to retrieve the
• Timon Gehr (3/25) Apr 17 2016 mixin(generate());
• Bauss (4/6) Apr 17 2016 That's not a solution to the problem, because you will be
• Timon Gehr (3/8) Apr 17 2016 Obviously you'll insert this specifically for the mixin that causes the
• Bauss (7/16) Apr 17 2016 I don't think you understand the issue. It's the same mixin but
• Adam D. Ruppe (5/8) Apr 17 2016 Why are your mixins so huge?
• Bauss (7/15) Apr 17 2016 My mixins are huge because I generate views, controllers and
• Nicholas Wilson (7/25) Apr 17 2016 I remember Deadalnix saying in one of his DConf talks on SDC that
• Timon Gehr (11/29) Apr 18 2016 I'm giving better alternative solutions than printing the offending

Bauss <streetzproductionz hotmail.com> writes:

Can there please be implemented something to retrieve the 
generated mixins that causes compiler errors; like perhaps a flag 
you pass that will print all mixins with compiler errors?

Sometimes when you create highly dynamic mixins it can be hard to 
identify errors in them, because you might not know exactly what 
code is generated.

I've had that issue multiple times with big mixins and it has 
been impossible to determine what the exact culprit of it is. I 
mean you get the line and stuff within the mixin, but sometimes 
that's not enough because you simply don't know the exact mixin 
string that's compiled.

Of course you can generate the mixin strings at runtime and print 
them out, but it can be a real hassle to translate compiletime 
data into runtime data to be able to generate the exact mixins. 
Sometimes it might not be an option either if your mixins rely on 
other mixins or simply because the data you rely on is too 
difficult to move.

I believe it would make compiler errors easier to handle for 
mixins if you could see the generated mixins, because you could 
pinpoint the issue to its exact location.

This might not be something that you face with small mixins, but 
I often deal with mixins of 100s - 1000s lines of code and it 
becomes really hard to deal with errors in them because I don't 
know what they exactly consists of.

Timon Gehr <timon.gehr gmx.ch> writes:

On 17.04.2016 23:18, Bauss wrote:
 Can there please be implemented something to retrieve the generated
 mixins that causes compiler errors; like perhaps a flag you pass that
 will print all mixins with compiler errors?

 Sometimes when you create highly dynamic mixins it can be hard to
 identify errors in them, because you might not know exactly what code is
 generated.

 I've had that issue multiple times with big mixins and it has been
 impossible to determine what the exact culprit of it is. I mean you get
 the line and stuff within the mixin, but sometimes that's not enough
 because you simply don't know the exact mixin string that's compiled.

 Of course you can generate the mixin strings at runtime and print them
 out, but it can be a real hassle to translate compiletime data into
 runtime data to be able to generate the exact mixins. Sometimes it might
 not be an option either if your mixins rely on other mixins or simply
 because the data you rely on is too difficult to move.

 I believe it would make compiler errors easier to handle for mixins if
 you could see the generated mixins, because you could pinpoint the issue
 to its exact location.

 This might not be something that you face with small mixins, but I often
 deal with mixins of 100s - 1000s lines of code and it becomes really
 hard to deal with errors in them because I don't know what they exactly
 consists of.


mixin(generate());
pragma(msg,generate());

Bauss <streetzproductionz hotmail.com> writes:

On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
 mixin(generate());
 pragma(msg,generate());

  That's not a solution to the problem, because you will be 
printing ALL mixins and not just the ones causing compilation 
errors.

Timon Gehr <timon.gehr gmx.ch> writes:

On 17.04.2016 23:49, Bauss wrote:
 On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
 mixin(generate());
 pragma(msg,generate());

   That's not a solution to the problem, because you will be printing ALL
 mixins and not just the ones causing compilation errors.

Obviously you'll insert this specifically for the mixin that causes the 
compilation error.

Bauss <streetzproductionz hotmail.com> writes:

On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote:
 On 17.04.2016 23:49, Bauss wrote:
 On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
 mixin(generate());
 pragma(msg,generate());

   That's not a solution to the problem, because you will be 
 printing ALL
 mixins and not just the ones causing compilation errors.

 Obviously you'll insert this specifically for the mixin that 
 causes the compilation error.

I don't think you understand the issue. It's the same mixin but 
with different parameters for the generation, thus this is not 
possible, because you don't know which one of the exact generated 
ones is the issue,

Like I also said this does not apply to normal mixins but usually 
very big mixins composited of multiple mixins and template mixins.

Adam D. Ruppe <destructionator gmail.com> writes:

On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote:
 Like I also said this does not apply to normal mixins but 
 usually very big mixins composited of multiple mixins and 
 template mixins.

Why are your mixins so huge?

But yeah, I would like to see it print the error line and a few 
surrounding lines here. I really wish we could overhaul the error 
system.

Bauss <streetzproductionz hotmail.com> writes:

On Sunday, 17 April 2016 at 23:10:38 UTC, Adam D. Ruppe wrote:
 On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote:
 Like I also said this does not apply to normal mixins but 
 usually very big mixins composited of multiple mixins and 
 template mixins.

 Why are your mixins so huge?

 But yeah, I would like to see it print the error line and a few 
 surrounding lines here. I really wish we could overhaul the 
 error system.

My mixins are huge because I generate views, controllers and 
models based on data given in the form of my custom mvc templates 
similar to how mvc and razor templates work in ASP.NET and thus 
it's a long chain of mixins to allow for all the generated 
classes and functions to operate together without having to do a 
lot of extra stuff.

Nicholas Wilson <iamthewilsonator hotmail.com> writes:

On Sunday, 17 April 2016 at 22:08:55 UTC, Bauss wrote:
 On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote:
 On 17.04.2016 23:49, Bauss wrote:
 On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
 mixin(generate());
 pragma(msg,generate());

   That's not a solution to the problem, because you will be 
 printing ALL
 mixins and not just the ones causing compilation errors.

 Obviously you'll insert this specifically for the mixin that 
 causes the compilation error.

 I don't think you understand the issue. It's the same mixin but 
 with different parameters for the generation, thus this is not 
 possible, because you don't know which one of the exact 
 generated ones is the issue,

 Like I also said this does not apply to normal mixins but 
 usually very big mixins composited of multiple mixins and 
 template mixins.

I remember Deadalnix saying in one of his DConf talks on SDC that 
SDC was capable of tracking mixin locations properly and would 
print something like

error on line 12 of mixin 'foo()', mixed in from line 45 of mixin 
'bar()' mixed in from line 8 of file baz.d

for a error nested in a chain of mixins.

Timon Gehr <timon.gehr gmx.ch> writes:

On 18.04.2016 00:08, Bauss wrote:
 On Sunday, 17 April 2016 at 21:59:38 UTC, Timon Gehr wrote:
 On 17.04.2016 23:49, Bauss wrote:
 On Sunday, 17 April 2016 at 21:23:58 UTC, Timon Gehr wrote:
 mixin(generate());
 pragma(msg,generate());

   That's not a solution to the problem, because you will be printing ALL
 mixins and not just the ones causing compilation errors.

 Obviously you'll insert this specifically for the mixin that causes
 the compilation error.

 I don't think you understand the issue.

I'm giving better alternative solutions than printing the offending 
mixin at runtime. The error messages could be improved too. What 
concrete suggestions do you have? (I.e., with details.)


 It's the same mixin but with
 different parameters for the generation, thus this is not possible,
 because you don't know which one of the exact generated ones is the issue,
 ...

AFAIK, the compiler is designed to identify them unambiguously.
In any case, you might be able to do something along the following lines:

static if(!__traits(compiles,{mixin(foo(params));}){
     pragma(msg,params);
     pragma(msg,foo(params));
}


 Like I also said

(Debatable.)

 this does not apply to normal mixins but usually very
 big mixins composited of multiple mixins and template mixins.