Suite Parameters Unexpectedly null If Run On Forks

[jstueckrath]

In some cases, parameters of suites are null, although proper values are provided. Run for instance the following script:

packagedef somepackage with
	
	forkdef aFork1
	forkdef aFork2
	forkdef aFork3
	forkdef aFork4
		
	testdef isNotNull uses integrity.string.TestFixture#isNotNull
		
	suitedef test1 with
			
		variable aVariable
		assign 10 -> aVariable
		suite testNotNull aParameterValue: aVariable on aFork2
			
		variable aVariable2
		suite generateAFour aReturnValue -> aVariable2 on aFork3
		test isNotNull object: aVariable2
			
		variable aVariable3
		assign 20 -> aVariable3
			
		suite testNotNull aParameterValue: aVariable3 on aFork1 // L1
		suite testNotNull aParameterValue: aVariable3 on aFork2 // L2
		suite testNotNull aParameterValue: aVariable3 on aFork3 // L3
		suite testNotNull aParameterValue: aVariable3 on aFork4 // L4
			
	suiteend
		
	private suitedef generateAFour returns aReturnValue with
		assign 4 -> aReturnValue
	suiteend
		
	private suitedef testNotNull gets aParameterValue with
		test isNotNull object: aParameterValue
	suiteend
	
packageend

which uses the fixture method (just to make the problem clear):

@FixtureMethod(description = "Check that '$object$' is not null.")
public Boolean isNotNull(@FixtureParameter(name = "object", mandatory = true) Object anObject) {
	return anObject != null;
}

One would expect that running the suite test1 would be green, but that is not the case. More precisely L2 and L3 are greedn, but L1 and L4 are not. In some cases the suite testNotNull is started with the parameter value null, although all three variables have a proper value. Curiously L3 seems to be green only because the suite generateAFour was called on the same fork before.
The problem seems occur when combining forks, local variables and suite parameters. The problem also occurs when variables 1 to 3 are not locally defined, but return variables (which have the same scope). However, all tests are green if variables 1 to 3 are not defined locall, but as package variables.

Note: The observations above where done with Integrity 0.17.11.

[jstueckrath]

This issue seems related to #150 and might even cause behaviour that could be mistaken for #150.

[S1artie]

This one was actually caused by an error in the "assign" statement processing with regard to forks. It should generally work like an assignment done with the "variable aVariable initially 10" definition variant, but that was not the case.

[jstueckrath]

I verified that the problem is fixed for the given Integrity script, but noticed that it still occurrs if fixture methods are used to assign variables instead of the assign statement. See #194.