www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Early exit error messages are unsustainable

reply Ethan <gooberman gmail.com> writes:
SOOOOOO

Since not many liked the idea of static assert behaving correctly 
(note for reference that C++'s static_assert will not stop 
compilation in at least MSVC and will give you all the error 
information you need), here's another example that's currently 
driving me up the wall.

Error: template instance `AliasSeq!( ... )` recursive template 
expansion

This one's the result of trying to compile my code in LDC. 
Symbols omitted because they're not important.

What is the important part? As a part of dealing with "recursive 
template expansion" last time the compiler didn't want to give me 
information, I determined that an AliasSeq will give that error 
if something fails to compile.

While tracking down another error, I discovered that LDC has 
issues with cross-module visibility and alias this. This code 
compiles just fine in online compiler testers:

struct Something
{
     enum Val = 5;
     int dummy;
}

struct SomethingElse
{
     Something derp;
     alias derp this;
}

pragma( msg, SomethingElse.Val.stringof );

But put it across modules (and, in my case, template the 
equivalent of SomethingElse) and things start going wrong in LDC.

Which leads me to the recursive expansion. Because whatever's 
going on wherever in my code, the compiler knows there's a 
problem and is refusing to tell me.

This code should have been compiling hours ago, and I should have 
been uploading this binary not long after.

These instances of the compiler stopping have cost me too much 
time. Counter arguments to this are just plain incorrect. Any 
given compiler *needs* to tell the user *why it's not compiling 
code*.

As it stands, it's a crapshoot hand-auditing about 10,000 lines 
of heavily templated D code right now trying to find out what the 
actual problem is. This is neither a fun nor entertaining nor 
productive use of my time.
Aug 13 2019
parent reply Ethan <gooberman gmail.com> writes:
On Tuesday, 13 August 2019 at 21:00:38 UTC, Ethan wrote:

 Which leads me to the recursive expansion. Because whatever's 
 going on wherever in my code, the compiler knows there's a 
 problem and is refusing to tell me.


Finally compiling and linking.

Whatever the problem is, it's not liking circular imports in my 
code.

Not that it bothered to tell me that.
Aug 13 2019
parent reply FeepingCreature <feepingcreature gmail.com> writes:
On Tuesday, 13 August 2019 at 22:36:09 UTC, Ethan wrote:

 On Tuesday, 13 August 2019 at 21:00:38 UTC, Ethan wrote:

 Which leads me to the recursive expansion. Because whatever's 
 going on wherever in my code, the compiler knows there's a 
 problem and is refusing to tell me.


 Finally compiling and linking.

 Whatever the problem is, it's not liking circular imports in my 
 code.

 Not that it bothered to tell me that.


Circular imports and circular dependencies have always been a 
minefield. They *work*, sort of, but not always reliably. A whole 
bunch of bugs have taken the form "I've used a circular 
dependency to confuse the compiler into treating a type as 
finished when it wasn't actually done figuring it out yet", 
especially around concepts like inspecting a type from a mixin 
template inside the type, and things like that.

As a language, D is always torn between "I want to take on big 
challenges and become more powerful!" and "Why did I do that! I 
regret that decision immediately!" Unfortunately, it's very hard 
to say "no, we've bit off too much complexity here, we should 
forbid this kind of construct." The temptation will always be to 
say "let's just focus on this next bug, this feature can work if 
we just fix all the issues with it" and ignore the fact that this 
many issues are a warning sign that a feature doesn't fit cleanly 
into the rest of the design.
Aug 13 2019
parent reply Sebastiaan Koppe <mail skoppe.eu> writes:
On Wednesday, 14 August 2019 at 06:50:11 UTC, FeepingCreature 
wrote:

 especially around concepts like inspecting a type from a mixin 
 template inside the type, and things like that.


The first time I tried something similar like that, I thought it 
will never compile. To my amazement it did. I still don't fully 
understand how it works, but I am glad it does.
Aug 14 2019
parent Ethan <gooberman gmail.com> writes:
On Wednesday, 14 August 2019 at 10:04:58 UTC, Sebastiaan Koppe 
wrote:

 On Wednesday, 14 August 2019 at 06:50:11 UTC, FeepingCreature 
 wrote:

 especially around concepts like inspecting a type from a mixin 
 template inside the type, and things like that.


 The first time I tried something similar like that, I thought 
 it will never compile. To my amazement it did. I still don't 
 fully understand how it works, but I am glad it does.


Yep, and I've been bitten before with mixins like that in 
Binderoo.

But this one. The only reason there was a circular import was to 
gain access to some struct UDAs.

In this case, I'd have to say "Even C can manage include 
guards/#pragma once".
Aug 14 2019