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.

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

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

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!