MUnit and MCover "Invalid package...should be " error

Question

Trying to compile the autogenerated example test (made with the standard haxelib run munit gen, then running with haxelib run munit t with or without -coverage) for a HaxeFlixel game (flash target), using MUnit 2.1.2 with Haxe 3.2.1 on Windows 7. I get:

HaxeWrapper.hx:73: --macro:1: character 0 : Invalid package : subfolder should be <empty>

...where subfolder is a subfolder of my main source directory. The game itself compiles fine, with references to subfolder.* (and subfolder.nestedsubfolder.* etc.) packages all over the place, but also some classes in source itself with the namespace simply package;.

The line number given doesn't exactly tell me what I might need to fix within my project...before I try digging (over my head) into HaxeWrapper.hx, is this a known issue with having subfolders/different package names within a project, or something?

BTW I have another project where this doesn't happen, but in that project, source only contains one subfolder, and everything in there shares that same package namespace (i.e. package subfolder;). (Hence my question.)

Update

I had mcover also working on my project earlier, just for a manual testing metric. Since then it grew a lot, and as a consequence, I organized things into package subfolders. Meanwhile I hadn't tried it with mcover enabled, because it made stepping during debugging more cumbersome. Now when I re-enable mcover, my project won't compile, giving the same error message as the above, but without the HaxeWrapper.hx:73: prefix.

Answer 1

I think this means you are autogenerating files into subfolder without package subfolder; in them. I have never heard of mcover before, but it seems a similar error message is produced at the point where some code causes Haxe to look in the filesystem for a Haxe class file and Haxe finds that the file does not have a package statement matching the path that Haxe found it at. However, it yields a different error than you’d expect.

Expected Error Example

subfolder/MyClass.hx:

class MyClass {
  public static function main() {
    Sys.println("hi");
  }
}

Output:

>haxe -cpp x.cpp subfolder.MyClass
Invalid commandline class : subfolder.MyClass should be MyClass

This is the error that I would expect to see when trying to access MyClass. However, it appears that this helpful error message only appears when Haxe is initially trying to resolve the class name specified as the entry point.

Same Cause, Different Error

Assuming you still have subfolder/MyClass.hx as described above, add a new class with a proper package statement:

subfolder/AnotherClass.hx:

package subfolder;

class AnotherClass {
  static function main() {
    MyClass.main();
  }
}

Output:

>haxe -cpp x.cpp subfolder.AnotherClass
subfolder/AnotherClass.hx:5: characters 4-11 : Invalid package : subfolder should be <empty>

If I go to AnotherClass.hx:5:5 (characters 4-11 seems to be 0-indexed?), I see MyClass. So really what it’s choking on is the fact that it expected to load subfolder.MyClass but after loading the module the module claimed that its fully qualified name is MyClass because it has no package statement.

Application to Question

So, to the best of my guess, your mcover stuff is generating files lacking the package statement. If it has an option like -namespace or -root-package or if you can tell it to analyze the . directory rather than ./subfolder, it might perform better. Are you passing the mcover tool a value other than the value you passed to haxe -cp?

Another idea, based on what mcover does, is that it is referencing a .hx file in your project which is missing package subfolder;. If I change AnotherClass.hx to not call MyClass.main(), I can successfully compile using subfolder.AnotherClass as an entry point. It seems that Haxe won’t even try to parse/read MyClass.hx if it isn’t referenced by the other code it is analyzing. With a coverage tool, the tool might try to wrap/autogenerate code which references all files it discovers, even ones that Haxe itself would normally not even compile. The point of this is, of course, to figure out what code never gets any coverage/never runs ;-).

In sum, if you can find the class name at the source code location referenced by the error message and then examine the .hx file that Haxe would load based on the class name, you might find a missing package statement. Though I’m not sure what you can do when the error doesn’t have the source code location.