Thread overview
[Issue 3879] New: compile-time assertion error in mtype.c: foreach through associative array w/ templated-class as value
Mar 04, 2010
njb303@gmail.com
Mar 04, 2010
Don
Mar 05, 2010
njb303@gmail.com
Mar 11, 2010
Don
March 04, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3879

           Summary: compile-time assertion error in mtype.c: foreach
                    through associative array w/ templated-class as value
           Product: D
           Version: 2.040
          Platform: x86_64
        OS/Version: Windows
            Status: NEW
          Severity: major
          Priority: P2
         Component: DMD
        AssignedTo: nobody@puremagic.com
        ReportedBy: njb303@gmail.com


--- Comment #0 from njb303@gmail.com 2010-03-04 11:10:38 PST ---
I'm working on a file with these classes so far:

abstract class State(T:GameEntity)
{
   string _name;
   @property {
       const string name() const { return _name; }

   this(string name)   { _name = name; }
   (and some empty virtual function decls that get defined by derived classes)
}  // and then the actual implementation for the various State nodes will be
done through derived classes

// so if I had a class DogRobot that derives from GameEntity, then it would
// internally use a StateMachine!(DogRobot), which itself would be using
// State!(DogRobot) for its states.  Somewhere in DogRobot.d it would also
// define those new State!(DogRobot)-derived classes that would then be
// added to the State Machine via addState()
class StateMachine(T:GameEntity)
{
   ...
   State!(T)[string] _states;   // THIS IS LINE 100 IN THE ERROR MESSAGES
MENTIONED LATER -- assoc array for quickly retrieving states by their names

   // public, actual state objects added to the machine here
   void addState(State!(T) state)
   {
      ... (compiles fine) ...
   }

   void linkStates(string fromName, string toName, string eventName)
   {
      ... (compiles fine) ...
   }

   // so far so good, further down I have a function called printGraph() for
debug output, and this is where I've run into assertion problems with DMD 2.040
compiler

   void printStates()
   {
       std.stdio.writefln("States:");
       // each and every one of these below causes a compile-time error,
       // though different ones sometimes:

       // this leads to error: "__overloadset is not a template" on line 100
       foreach (string key, State!(T); _states)
          std.stdio.writefln("  %1", key);

       // the rest of these each, individually, result in an assertion error
       // at compile-time which pops up twice.

       // In the actual code I commented-out the previous problematic lines
       // before trying the next approach/flavor.  DMD 2.040 compiler's error
       // for each of these reads as follows:
       //
       // Assertion failure: 'impl' on line 3886 in file 'mtype.c'
       //
       // abnormal program termination
       // Assertion failure: 'impl' on line 3886 in file 'mtype.c'
       //
       // abnormal program termination

       // Various problematic code for THIS error is as follows:

       // first attempt
       foreach (string k; _states.keys)
          std.stdio.writefln("  %1", k);

       // approach #2
       foreach (State!(T) s; _states.values)
          std.stdio.writefln("  %1", s.name);

       // approach #3, but char[] k for a string-type key is probably
       //    incorrect in a different way I'm guessing... just a desperation
try
       foreach (char[] k; _states.keys.sort)
          std.stdio.writefln("  %1", k);

       // approach #4
       typedef State!(T) tstate;
       foreach (tstate s; _states.values)
          std.stdio.writefln("  %1", s.name);
   }  // end printStates()
}  // end StateMachine class

// end code snippet

In the meantime I can probably get around this problem by getting rid of templates entirely and very carefully using delegates to act as "plugged-in behavior"... I was following the approach in an AI book I have, but there are other ways I can go about doing the same thing, I'm sure.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 04, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3879


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clugdbug@yahoo.com.au


--- Comment #1 from Don <clugdbug@yahoo.com.au> 2010-03-04 11:32:14 PST ---
This sounds like a duplicate of bug 3692.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 05, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3879



--- Comment #2 from njb303@gmail.com 2010-03-05 12:07:18 PST ---
(In reply to comment #1)
> This sounds like a duplicate of bug 3692.

I took a look at that bug and did a little further tinkering.  It seems you might be correct.

I just removed the std.variant import directive that I hadn't mentioned (not thinking it had anything to do with the problem) and commented-out an unrelated class definition in the same file that used Variant, and the results are now:

1) The first line, that gave "__overloadset is not a template on line 100", now compiles fine.

2) The "foreach (string k; _states.keys)" approach now compiles fine.

3) The "foreach (State!(T) s; _states.values)" approach now compiles fine.

4) The "foreach (char[] k; _states.keys.sort)" approach now gives an
appropriate error message (cannot implicily convert expression etc) instead of
crashing with an assertion.

5) The final approach where I do declare State!(T) as a new typedef called 'tstate' and then do "foreach (tstate s; _states.values)" gives an error message instead of crashing -- "cannot implicitly convert expression"... which is surprising, though unrelated to what this bug report is about, and I'm not sure if I should submit another report on this particular thing because maybe doing typedefs on templated-classes is intentionally not-allowed?

Anyway, I think you're right... removing any and all mention of std.variant from the source file changed the situation entirely.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
March 11, 2010
http://d.puremagic.com/issues/show_bug.cgi?id=3879


Don <clugdbug@yahoo.com.au> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


--- Comment #3 from Don <clugdbug@yahoo.com.au> 2010-03-10 23:52:46 PST ---
Since bug 3692 is fixed in DMD2.041, this one should be working now. Reopen if it that is not correct.

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------