Expander refactoring [property tracking analyzers prerequisity] #10102
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 ofnull
- so we end up with literaly hundrets of calling paths where we cannot be sure whetherLoggingContext
is available or not. TheLoggingContext
is appealing for a data pub-sub, so let's make sure it's available throughout theExpander
calls, while at the same let's simplify the code a bitChanges Made
Expander
to passLoggingContext
wherever possible (the only exception is the Expander usages from the ToolsetReader - where we do not know the build context yet).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
ItemBucket.UpdateLoggingContext
Reason: The single differing case was in
TargetEntry.ExecuteTarget
whereProjectLoggingContext
was used to construct theExpander
, but thenTargetLogginContext
was used to transitively call the methods. So the updating of the context was used to bridge this casePropertyTrackingEvaluatorDataWrapper
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 requestedUsedUninitializedProperties
->PropertiesUsageTracker
PropertiesUsageTracker
Testing
Refactored and resued existing tests (as there is no new functionality)