Contributes to #9883 (spinoff from #10009 - focusing on parts not related to BuildCheck)
Note
There is no new functionality in this PR - just refactoring and code moving. It is required for the followup PR(s) for property tracking analyzers
Context
Expander is using LoggingContext in some of the execution paths, but in it usually has a default value of null - so we end up with literaly hundrets of calling paths where we cannot be sure whether LoggingContext is available or not. The LoggingContext is appealing for a data pub-sub, so let's make sure it's available throughout the Expander calls, while at the same let's simplify the code a bit
Changes Made
Added constructors to Expander to pass LoggingContext wherever possible (the only exception is the Expander usages from the ToolsetReader - where we do not know the build context yet).
Removed explicit LoggingContext arg from the Expander methods
Reason: Went through all the methods in Expander and all the possible caller chains (there were many hunderts of them) - and found out there is just a single case where LoggingContext passed to expander calls differ from the LoggingContext used to construct the Expander
Added ItemBucket.UpdateLoggingContext
Reason: The single differing case was in TargetEntry.ExecuteTarget where ProjectLoggingContext was used to construct the Expander, but then TargetLogginContext was used to transitively call the methods. So the updating of the context was used to bridge this case
Moved the conditioning of PropertyTrackingEvaluatorDataWrapper into the type - so that in the folowup PR we can use the type to feed data to analyzers even if proprty tracking logging is not requested
Contributes to #9883 (spinoff from #10009 - focusing on parts not related to BuildCheck)
Note
There is no new functionality in this PR - just refactoring and code moving. It is required for the followup PR(s) for property tracking analyzers
Context
Expander is using
LoggingContextin some of the execution paths, but in it usually has a default value ofnull- so we end up with literaly hundrets of calling paths where we cannot be sure whetherLoggingContextis available or not. TheLoggingContextis appealing for a data pub-sub, so let's make sure it's available throughout theExpandercalls, while at the same let's simplify the code a bitChanges Made
Expanderto passLoggingContextwherever possible (the only exception is the Expander usages from the ToolsetReader - where we do not know the build context yet).ItemBucket.UpdateLoggingContextReason: The single differing case was inTargetEntry.ExecuteTargetwhereProjectLoggingContextwas used to construct theExpander, but thenTargetLogginContextwas used to transitively call the methods. So the updating of the context was used to bridge this casePropertyTrackingEvaluatorDataWrapperinto the type - so that in the folowup PR we can use the type to feed data to analyzers even if proprty tracking logging is not requestedUsedUninitializedProperties->PropertiesUsageTrackerPropertiesUsageTrackerTesting
Refactored and resued existing tests (as there is no new functionality)