oorexx5 macos
also reproductible with oorexx4
In case of circular requires, some public classes are not made visible because they were not yet installed when executing PackageClass::mergeRequired.
No problem with the routines.
Test case (attached files):
package p1.cls defines public class C1 and public routine R1
package p2.cls defines public class C2 and public routine R2
p0.rex requires p1.cls
p1.cls requires p2.cls
p2.cls requires p1.cls (circular)
p2.cls sees R1 but doesn't see C1.
In PackageClass::mergeRequired where this==p2.cls and mergeSource==p1.cls, we have:
mergeSource->installedPublicClasses is NULL
mergeSource->mergedPublicClasses is NULL
mergeSource->classes is not NULL and could be used to get the list of public classes to merge.
Not sure what should be the fix...
a) reject because it's a bad design to have such circularity for classes ?
b) don't touch the implementation and update the documentation ?
c) maybe the public classes without method 'activate' could be merged ? they can be found with mergeSource->classes.
d) raise an error if one of the public classes in mergeSource->classes has a method 'activate' ?
Also not sure if that impacts the "installation time constant calculations" in PackageClass::processInstall.
Anonymous
There's a fair amount of code to track circular loading of requires files. Unfortunately, the two places where the checks are performed end up being a noop because they call a method that just returns a boolean result. This was clearly intended to raise an error, although there doesn't appear to be an error message for the condition defined.
Fix added in [r12499] to properly detect circular references with ::requires
Related
Commit: [r12499]