Why is the error message coming by the end of the compilation?

[bauss]

On Saturday, 14 April 2018 at 17:58:20 UTC, Steven Schveighoffer 
wrote:
> On 4/14/18 4:16 AM, bauss wrote:
>> 
>> I tried to use __traits(compiles) but it always returns false 
>> for the code I'm going to mixin, even though it's valid, that 
>> was my initial go to, so this is really a second attempt on 
>> something to give meaningful error messages when certain 
>> mixins don't compile.
>> 
>
> Hm.. that seems annoying. I'd guess you'd get simple tests to 
> work, maybe it's the way you are using __traits(compiles).
>
> If all else fails, back out to the place where you are using 
> it. At some point, it is a function call. Just wrap that call, 
> and check if it compiles or not.
>
> e.g.:
>
> static assert(__traits(compiles, theFunction(theItem), "this 
> code won't compile: " ~ theItem.source);
>
> // if we get here, it will compile
> theFunction(theItem);
>
> D can be quite perplexing when you have so much meta in it :)
>
> -Steve

All I mixin is a class, but the class itself can be pretty big 
and have all kinds of complexity.

What I first tried was using __traits(compiles, source) without 
anything, then I tried to make a wrapper function that simply did 
it but nothing works with it.

I know there are a few things that you can't test directly with 
__traits(compiles) since it has its limits, but a class shouldn't 
be one of them.

I think it's kind of hard to demonstrate what exactly I'm doing 
unless you have the code, but even so I don't see a way around it.

What I'm trying to achieve is getting a way from one big mixin 
with all the source code using join() on an array of strings, so 
I can give sensible error messages to the user, since right now 
you have to know which file you made an error in, because you 
have no information like that except for what line in the mixin 
the error is.

That is okay when you have let's say 10 lines of code, but in my 
case each mixin can span well over hundreds of lines of code or 
even more.

And the code the user see is not the same code that is within the 
mixin, so you can't use the line numbers for anything, because 
the code the user made is parsed and translated into other pieces 
of D code which is put into the function of a class and then that 
class is what the mixin actually is.

It's kind of complex.

I wish there was a way to give a mixin some kind of identity like:

mixin("mymixin", "somecode");

Where an error message would print something like:

Error in mixin("mymixin"): ...

That would completely solve this issue and I wouldn't have to 
have pragma(msg) all over the place.

I'm not sure whether such a proposal would be worth it, but in my 
case that would help a lot, but I'd guess it would need a DIP?