Open dalehenrich opened 4 years ago
Interesting anomaly noted while characterizing this bug ... large number of classesWithPropertyChanges
and classesWithClassVariableChanges
, yet looking at the diff between 869fc25f and ba6a4221 I haven't seen any *explicit changes to class properties ...
reported as #558...
Here's the analysis of the state of RwGsPatchSet_254 at the point of error:
deletedPackages
aRwPackageDefinition for Rowan-GemStone-SpecificationsV2
extendedClasses
Collection
SequenceableCollection
RwSpecification
classesWithPropertyChanges & classesWithClassVariableChanges & createdClasses (https://github.com/GemTalk/Rowan/issues/558)
addedMethods
RwProjectComponentVisitorV2Test>>_visitVastTonelDemo_555:projectAlias:projectPath:
RwResolvedProjectV2 class>>loadSpecification:platformAttributes:
RwProjectComponentVisitorV2Test>>testVisitVastTonelDemo_555_independent
RwResolvedProjectV2>>resolve:
deletedMethods
RwProjectComponentVisitorV2Test>>_visitorClass
movedMethods
!!!!
extendedMethods
Collection>>sort:
RwLoadSpecificationV2>>resolve:
RwProjectComponentVisitorV2Test>>_readVastTonelDemo_555:deleteClone:
RwProjectComponentVisitorV2Test>>_cloneVastTonelDemo_555:deleteClone:
SequenceableCollection>>writeStreamPortable
RwAbstractProjectLoadComponentV2 class>>fromFile:
RwProjectComponentVisitorV2Test>>testReadVastTonelDemo_555
CharacterCollection>>substrings:
methodsWithPropertyChanges
RwLoadSpecificationV2>>gemstoneSetDefaultUseSessionMethodsForExtensionsForUser:to:
RwLoadSpecificationV2>>gemstoneDefaultMethodEnvForUser:
RwLoadSpecificationV2>>_gemstoneDefaultMethodEnv
RwLoadSpecificationV2 class>>_gemstoneAllUsersName
RwAbstractProjectLoadComponentV2 class>>fromUrl:
RwLoadSpecificationV2>>gemstoneSetDefaultSymbolDictNameForUser:to:
RwLoadSpecificationV2>>gemstoneSetDefaultMethodEnvForUser:to:
RwLoadSpecificationV2>>gemstoneSetDefaultMethodEnvTo:
... [ but not Collection>>sort:, which is the method causing the error ]
methodsNeedingRecompile
RwAbstractReaderWriterVisitor class>>_repositoryPropertyDictFor:
RwAbstractProjectLoadComponentV2 class>>fromUrl:
RwSpecification class>>_supportedPlatformNames
The method(s) that are causing the errors are in the list of extendedMethods (Collection>>sort: and SequenceableCollection>>writeStreamPortable have shown up during debugging) ...
extendedMethods
are recompiled whether or not the methods have changed source ... and these two cases the method source has not changed and the target class has not changed (only the package membership and method protocols have changed) ...
This particular error was added in this commit and it was added because no check was made for an existing method in the class with the same selector, so it is possible that in the wild two packages could have the same extension method for the same class ... need some explicit tests for this issue ...
, so this particular error is more fallout from adding this error condition being added ... the following tests are known to have been failing with the same error message:
The naive test case (RwRowanSample9Test>>testSpec_0016_to_0017) is to simply move an extension method from one package to another, but when that is done, the moved method ends up in movedMethods
, not extendedMethods
... and that distinction is important, since the methods in extendedMethods are compiled and movedMethods
are not...
Turns out that the methods are ending up in extendedMethods instead of movedMethods, because the methods are coming from a different project (Tonel-GemStone-Kernel) and in the case of my current experiments (so far) I am looking at only loading Rowan
, so the methods end up being stolen from the Tonel project and are showing up as extensionMethods in Rowan-GemStone-Components-Kernel ... this implies that the method stealing logic
be improved
The logic in RowanProjectService>>reloadProject should be improved to load all selected projects at once, since right now Jadeite is loading one project at a time, so cross-project method moves will always be subjected to this issue ... of course a second alternative is to update the logic surrounding the error message to be more forgiving and/or more intelligent ...
Deferring work until I start tackling multi-project loads in earnest ..
Notes:
869fc25f
Tonel-GemStone-Kernel
Collection>>sort:
ba6a4221
Rowan-GemStone-Components-Kernel
Collection>>sort:
RwRowanSample9Test >> testIssue830_3b is a relatively simple reproduction of the bug ... in case a simple test case is needed ... in this case, an existing method is NOT in a package. recompile, new method source and move to a package (runs afoul of the hack where the source is checked to see if it is the same).