On 08.09.2017 03:18, bitwise wrote:
Lately, I've been hit by several compilation errors when phobos fails to
construct an instance of a class or struct I've pass it. Regardless of
what the exact failure is, phobos usually gives you some generic error
that isn't helpful.
Example:
class Test {
@disable this();
}
int main(string[] argv) {
auto sz = __traits(classInstanceSize, Test);
auto mem = malloc(sz)[0..sz];
emplace!Test(mem);
return 0;
}
The above code fails with this error:
'Error: static assert "Don't know how to initialize an object of type
Test with arguments ()"'
@disable'd constructors are only one of the reasons I've hit this snag.
Once though, I was having an extremely hard time figuring out what was
wrong, and the fix was simply to modify emplace(). I removed the line
below from emplace(), and forced the constructor call, which led to a
much more helpful error.
`// static if (is(typeof(result.__ctor(args1))))`
If you simply did that though, it may not be obvious to everyone what
happened, but if you had __traits(compilerError, {}) then you could
dress the error up as appropriate:
"Emplace failed with error:\n\t'" ~ __traits(compileError, {
result.__ctor(args1) }) ~ "."
The alternative would be to manually code redundant error checks that
the compiler already does into everything in phobos that needs to
construct objects, which seems much worse than implementing something
like __traits(compileError, {}).
Thoughts?
The dangerous thing about this suggestion is that it makes the
compilation errors DMD implements de facto part of the semantics of the
D language. I.e. improving compiler diagnostics becomes a breaking
language change.
