pFUnit

pFUnit copied to clipboard

I am trying to test a module that makes use of the variable T. When the pfunit preprocessor converts the pfunit file to an f90 file, it also makes use of the variable T in the function printMakeSuite(), in the line "class(Test), allocatable :: t", causing an attribute conflict. Is there a prescribed method of resolving this conflict on the pfunit side? (I cannot rename the variables in the module I am trying to test)

The function in question:

def printMakeSuite(self): self.outputFile.write('function ' + self.suiteName + '() result(suite)\n') self.outputFile.write(' use FUnit\n') if (self.userModuleName): self.outputFile.write(' use ' + self.userModuleName + '\n') self.outputFile.write(' use '+ self.wrapModuleName + '\n') self.outputFile.write(' implicit none'+ '\n') self.outputFile.write(' type (TestSuite) :: suite\n\n') self.outputFile.write(' class (Test), allocatable :: t\n\n')

Interesting. I'm actually a bit surprised this has not come up before, as t is hardly a rare variable name. (Perhaps a bit rare as a public module variable ...)

The t in that function is actually only there as a concession to compilers that do not properly support F2008 polymorphic assignment. Probably too risky for me to make that swap - I don't want to break support for older compiler versions if I can help it.

And it would of course be simple enough to just switch to another variable name here that is less likely to conflict like t_private_ or something ugly like that. (To be fair, even just a trailing underscore would probably be good enough in the practical sense.)

Another solution would be to wrap each addTest() with a BLOCK construct, and move the declaration of t in there. Or even create a small internal procedure.

All of these solution involve several changes in ./bin/funit/pFUnitParser.py, unfortunately.

I'm between two vacations at the moment and won't have time to actually implement and test anything along these lines until ~ June 18th or so. If encourage you to try any of the above as a workaround for now. And then I can roll out a release when I'm back.

Thanks for the reply! I was able to eliminate the conflict by removing the t variable I added from the test module's namespace once I had better grasped the issue. So thankfully this isn't a problem for me anymore. If you would prefer to leave it as is that is perfectly fine with me.