www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Why is the error message coming by the end of the compilation?

reply bauss <jj_1337 live.dk> writes:
I can't seem to reproduce this with any other smaller projects, 
so my question is really what could trigger this behavior.

See: https://i.imgur.com/OmqJ8Sr.png

Whenever I try to just do this kind of thing by itself then it 
behaves correctly.

Ex: (As you can see it prints the error messages in the order it 
should.)
https://run.dlang.io/

What I'm doing is basically this:
     static foreach (viewResult; generateViewsResult)
     {
       pragma(msg, "Compiling: " ~ viewResult.name);
       mixin(viewResult.source);
       pragma(msg, "Compiled: " ~ viewResult.name);
     }

I would've expect the compiling to be before the error message, 
but the compiled after the error message.

However it seems like it doesn't do that, but as I can't 
reproduce it I'm just wondering what causes it.

I'm suspecting that it's something to do with dub and that it's 
within a dependency that's compiled as a source library, but I've 
yet to test it out completely.

It's really impossible to debug mixins when you have no idea 
which mixin the error actually come from, which is what I'm 
trying to solve.
Apr 13 2018
next sibling parent bauss <jj_1337 live.dk> writes:
On Friday, 13 April 2018 at 20:50:38 UTC, bauss wrote:

 https://run.dlang.io/


Sorry posted wrong link for run.dlang.io.

https://run.dlang.io/is/HQlbgv
Apr 13 2018
prev sibling next sibling parent reply Ikeran <dhasenan ikeran.org> writes:
On Friday, 13 April 2018 at 20:50:38 UTC, bauss wrote:

 What I'm doing is basically this:
     static foreach (viewResult; generateViewsResult)
     {
       pragma(msg, "Compiling: " ~ viewResult.name);
       mixin(viewResult.source);
       pragma(msg, "Compiled: " ~ viewResult.name);
     }

 I would've expect the compiling to be before the error message, 
 but the compiled after the error message.

 However it seems like it doesn't do that, but as I can't 
 reproduce it I'm just wondering what causes it.


The compiler is free to examine your source code in any order 
that produces the same artifacts on success and self-consistent 
error messages otherwise. In this case, it evaluated the pragmas 
and the `mixin` in one pass, then the function body in a separate 
pass.

The best way I've found to debug mixins is to pragma(msg) the 
code I wanted to mix in, then insert it myself.
Apr 13 2018
parent reply bauss <jj_1337 live.dk> writes:
On Friday, 13 April 2018 at 21:20:26 UTC, Ikeran wrote:

 On Friday, 13 April 2018 at 20:50:38 UTC, bauss wrote:

 What I'm doing is basically this:
     static foreach (viewResult; generateViewsResult)
     {
       pragma(msg, "Compiling: " ~ viewResult.name);
       mixin(viewResult.source);
       pragma(msg, "Compiled: " ~ viewResult.name);
     }

 I would've expect the compiling to be before the error 
 message, but the compiled after the error message.

 However it seems like it doesn't do that, but as I can't 
 reproduce it I'm just wondering what causes it.


 The compiler is free to examine your source code in any order 
 that produces the same artifacts on success and self-consistent 
 error messages otherwise. In this case, it evaluated the 
 pragmas and the `mixin` in one pass, then the function body in 
 a separate pass.

 The best way I've found to debug mixins is to pragma(msg) the 
 code I wanted to mix in, then insert it myself.


The problem is I can't pragma(msg) the code I want to mixin 
manually since all mixins are dynamically generated. That's why 
my only way is to do it within that static foreach.

I have no control over how many mixins there are and only to an 
extend what they contains.

Basically what I'n doing is I have a file named views.config in 
which each like contains something like:

name|file.dd

The name is what's in viewResult.name and the content of file.dd 
is what's in viewResult.source (But parsed and wrapped into a 
valid D class)

I initially tried to just use __traits(compiles) but it fails 
even on the valid generated D code.
Apr 14 2018
parent reply Simen =?UTF-8?B?S2rDpnLDpXM=?= <simen.kjaras gmail.com> writes:
On Saturday, 14 April 2018 at 08:20:51 UTC, bauss wrote:

 The problem is I can't pragma(msg) the code I want to mixin 
 manually since all mixins are dynamically generated. That's why 
 my only way is to do it within that static foreach.


Wat.

So the compiler is able to generate the string you want to mixin, 
but not print it?

If you try this:

     static foreach (viewResult; generateViewsResult)
     {
         pragma(msg, "Compiling: " ~ viewResult.name);
         pragma(msg, viewResult.source);
         pragma(msg, "Compiled: " ~ viewResult.name);
     }

Does it blow up? Does it print gibberish? Does it complain in any 
way?



 I initially tried to just use __traits(compiles) but it fails 
 even on the valid generated D code.


This also sounds weird. Are you missing brackets around the 
generated code? If the generated code consists of more than one 
expression, you generally have to check __traits(compiles, { 
mixin(foo()); }).

 From reading your messages here it seems the mixin simply 
contains a class. This test shows the difference:

enum s = "class A {}";

// Global scope:
static assert(!__traits(compiles, mixin(s)));
static assert(__traits(compiles, { mixin(s); }));

unittest {
     // Function scope:
     static assert(!__traits(compiles, mixin(s)));
     static assert(__traits(compiles, { mixin(s); }));
}

As we can see, the version with extra brackets compiles, the 
other does not.



 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 seems like a very good idea. Posted it in D.general:
https://forum.dlang.org/post/epqmzhjoyqcdqrqksuvf forum.dlang.org

--
   Simen
Apr 15 2018
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 15 April 2018 at 10:14:56 UTC, Simen Kjærås wrote:

 On Saturday, 14 April 2018 at 08:20:51 UTC, bauss wrote:

 The problem is I can't pragma(msg) the code I want to mixin 
 manually since all mixins are dynamically generated. That's 
 why my only way is to do it within that static foreach.


 Wat.

 So the compiler is able to generate the string you want to 
 mixin, but not print it?

 If you try this:

     static foreach (viewResult; generateViewsResult)
     {
         pragma(msg, "Compiling: " ~ viewResult.name);
         pragma(msg, viewResult.source);
         pragma(msg, "Compiled: " ~ viewResult.name);
     }

 Does it blow up? Does it print gibberish? Does it complain in 
 any way?



 I initially tried to just use __traits(compiles) but it fails 
 even on the valid generated D code.


 This also sounds weird. Are you missing brackets around the 
 generated code? If the generated code consists of more than one 
 expression, you generally have to check __traits(compiles, { 
 mixin(foo()); }).

 From reading your messages here it seems the mixin simply 
 contains a class. This test shows the difference:

 enum s = "class A {}";

 // Global scope:
 static assert(!__traits(compiles, mixin(s)));
 static assert(__traits(compiles, { mixin(s); }));

 unittest {
     // Function scope:
     static assert(!__traits(compiles, mixin(s)));
     static assert(__traits(compiles, { mixin(s); }));
 }

 As we can see, the version with extra brackets compiles, the 
 other does not.



 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 seems like a very good idea. Posted it in D.general:
 https://forum.dlang.org/post/epqmzhjoyqcdqrqksuvf forum.dlang.org

 --
   Simen


Tried in brackets already, also tried to wraper 
__traits(compiles) into a function and given __traits(compiles) a 
function that has the code mixin.

It does not print gibberish and the code is valid, but 
__traits(compiles) still returns false for it.

On Sunday, 15 April 2018 at 10:27:26 UTC, ag0aep6g wrote:

 On 04/14/2018 08:56 PM, bauss wrote:

 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.


 The `#line` thing might help:

 ----
 void main()
 {
     mixin("#line 1 \"mymixin\"\n" ~ "somecode;");
         /* mymixin(1): Error: undefined identifier somecode */
     somecode;
         /* test.d(5): Error: undefined identifier somecode */
 }
 ----

 https://dlang.org/spec/lex.html#special-token-sequence


I don't see how the #line will help because you don't know which 
mixin the line would be associated with as they can come in any 
order.
Apr 15 2018
parent reply ag0aep6g <anonymous example.com> writes:
On 04/15/2018 05:33 PM, bauss wrote:

 On Sunday, 15 April 2018 at 10:27:26 UTC, ag0aep6g wrote:

 On 04/14/2018 08:56 PM, bauss wrote:

 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"): ...






[...]

     mixin("#line 1 \"mymixin\"\n" ~ "somecode;");
         /* mymixin(1): Error: undefined identifier somecode */




[...]

 I don't see how the #line will help because you don't know which mixin 
 the line would be associated with as they can come in any order.


I don't follow. It's not about setting the line number. The point is 
setting the source file name to "mymixin".

You asked for a way associate a name with a string mixin, and have that 
name included in errors. As far as I see, `#line` lets you do that.

Note how the error message in my example shows "mymixin".
Apr 15 2018
parent reply bauss <jj_1337 live.dk> writes:
On Sunday, 15 April 2018 at 15:55:15 UTC, ag0aep6g wrote:

 On 04/15/2018 05:33 PM, bauss wrote:

 On Sunday, 15 April 2018 at 10:27:26 UTC, ag0aep6g wrote:

 On 04/14/2018 08:56 PM, bauss wrote:

 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"): ...






 [...]

     mixin("#line 1 \"mymixin\"\n" ~ "somecode;");
         /* mymixin(1): Error: undefined identifier somecode */




 [...]

 I don't see how the #line will help because you don't know 
 which mixin the line would be associated with as they can come 
 in any order.


 I don't follow. It's not about setting the line number. The 
 point is setting the source file name to "mymixin".

 You asked for a way associate a name with a string mixin, and 
 have that name included in errors. As far as I see, `#line` 
 lets you do that.

 Note how the error message in my example shows "mymixin".


Oh, I'm sorry I didn't notice that, my bad.

I guess adding that would be the equivalent to what my proposal 
is.

I'll give it a try and come back
Apr 15 2018
parent bauss <jj_1337 live.dk> writes:
On Sunday, 15 April 2018 at 16:55:36 UTC, bauss wrote:

 On Sunday, 15 April 2018 at 15:55:15 UTC, ag0aep6g wrote:

 On 04/15/2018 05:33 PM, bauss wrote:

 On Sunday, 15 April 2018 at 10:27:26 UTC, ag0aep6g wrote:

 On 04/14/2018 08:56 PM, bauss wrote:

 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"): ...






 [...]

     mixin("#line 1 \"mymixin\"\n" ~ "somecode;");
         /* mymixin(1): Error: undefined identifier somecode 
 */




 [...]

 I don't see how the #line will help because you don't know 
 which mixin the line would be associated with as they can 
 come in any order.


 I don't follow. It's not about setting the line number. The 
 point is setting the source file name to "mymixin".

 You asked for a way associate a name with a string mixin, and 
 have that name included in errors. As far as I see, `#line` 
 lets you do that.

 Note how the error message in my example shows "mymixin".


 Oh, I'm sorry I didn't notice that, my bad.

 I guess adding that would be the equivalent to what my proposal 
 is.

 I'll give it a try and come back


It's almost as good as I want it to be, so this solution will do 
for now!
Apr 15 2018
prev sibling parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
On 4/13/18 4:50 PM, bauss wrote:

 I can't seem to reproduce this with any other smaller projects, so my 
 question is really what could trigger this behavior.
 
 See: https://i.imgur.com/OmqJ8Sr.png
 
 Whenever I try to just do this kind of thing by itself then it behaves 
 correctly.
 
 Ex: (As you can see it prints the error messages in the order it should.)
 https://run.dlang.io/
 
 What I'm doing is basically this:
      static foreach (viewResult; generateViewsResult)
      {
        pragma(msg, "Compiling: " ~ viewResult.name);
        mixin(viewResult.source);
        pragma(msg, "Compiled: " ~ viewResult.name);
      }
 
 I would've expect the compiling to be before the error message, but the 
 compiled after the error message.


It may be on a later semantic pass that the error occurs, I'm not sure. 
Only thing I can think of.


 
 However it seems like it doesn't do that, but as I can't reproduce it 
 I'm just wondering what causes it.
 
 I'm suspecting that it's something to do with dub and that it's within a 
 dependency that's compiled as a source library, but I've yet to test it 
 out completely.


Try verbose output maybe?


 
 It's really impossible to debug mixins when you have no idea which mixin 
 the error actually come from, which is what I'm trying to solve.


You may want to try using __traits(compiles) in a debug version to see 
whether it will compile or not, and if not, print the thing you are 
trying to compile.

-Steve
Apr 13 2018
parent reply bauss <jj_1337 live.dk> writes:
On Friday, 13 April 2018 at 21:22:13 UTC, Steven Schveighoffer 
wrote:

 On 4/13/18 4:50 PM, bauss wrote:

 I can't seem to reproduce this with any other smaller 
 projects, so my question is really what could trigger this 
 behavior.
 
 See: https://i.imgur.com/OmqJ8Sr.png
 
 Whenever I try to just do this kind of thing by itself then it 
 behaves correctly.
 
 Ex: (As you can see it prints the error messages in the order 
 it should.)
 https://run.dlang.io/
 
 What I'm doing is basically this:
      static foreach (viewResult; generateViewsResult)
      {
        pragma(msg, "Compiling: " ~ viewResult.name);
        mixin(viewResult.source);
        pragma(msg, "Compiled: " ~ viewResult.name);
      }
 
 I would've expect the compiling to be before the error 
 message, but the compiled after the error message.


 It may be on a later semantic pass that the error occurs, I'm 
 not sure. Only thing I can think of.


 
 However it seems like it doesn't do that, but as I can't 
 reproduce it I'm just wondering what causes it.
 
 I'm suspecting that it's something to do with dub and that 
 it's within a dependency that's compiled as a source library, 
 but I've yet to test it out completely.


 Try verbose output maybe?


 
 It's really impossible to debug mixins when you have no idea 
 which mixin the error actually come from, which is what I'm 
 trying to solve.


 You may want to try using __traits(compiles) in a debug version 
 to see whether it will compile or not, and if not, print the 
 thing you are trying to compile.

 -Steve


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.
Apr 14 2018
parent reply Steven Schveighoffer <schveiguy yahoo.com> writes:
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
Apr 14 2018
parent reply bauss <jj_1337 live.dk> writes:
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?
Apr 14 2018
parent ag0aep6g <anonymous example.com> writes:
On 04/14/2018 08:56 PM, bauss wrote:

 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.


The `#line` thing might help:

----
void main()
{
     mixin("#line 1 \"mymixin\"\n" ~ "somecode;");
         /* mymixin(1): Error: undefined identifier somecode */
     somecode;
         /* test.d(5): Error: undefined identifier somecode */
}
----

https://dlang.org/spec/lex.html#special-token-sequence
Apr 15 2018