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?
