Skip to content

Conversation

@KirillOsenkov
Copy link
Member

This PR supersedes #6514

Console logger support for IncludeEvaluationPropertiesAndItems.

Includes #6520, but we can take this commit out if it's merged separately.

OutputItems was pretty much duplicated in ParallelConsoleLogger. Unify with the base implementation and extract methods that need to be replaced by the derived type.

Support for reading project configuration description either from ProjectStartedEventArgs.Items or ProjectEvaluationFinishedEventArgs.Items.

Skip TestItemsWithUnexpandableMetadata. Issue #6518 is tracking. More work is needed to understand the desired behavior of the system under test and then fix the test to test the desired behavior.

Skip NullMetadataOnLegacyOutputItems_InlineTask. The feature the test is testing is broken, but the test passes because it doesn't specify diag verbosity for its logger. We will only log task outputs with diag verbosity. Issue #6521 is tracking.

Opt test out of LogPropertiesAndItemsAfterEvaluation. OutOfProcNodeForwardCertainproperties is explicitly testing a feature where only some properties are forwarded from a different process on ProjectStartedEventArgs. When we move properties to ProjectEvaluationFinished the test loses meaning. So force it into the old behavior via an escape hatch.

Copy link
Contributor

@Forgind Forgind left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this should work, though some of the unification with BaseConsoleLogger was hard to follow. Most worried about the possible NRE.

_includeEvaluationPropertiesAndItems = sinks.Any() && sinks.All(sink => sink.IncludeEvaluationPropertiesAndItems);
}

return _includeEvaluationPropertiesAndItems ?? false;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it possible for it to still be null here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sorry what? the nullable? no, it will be assigned to a boolean on line 523, but that doesn't convince the compiler, so I had to add ?? false to convert the bool? to bool

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok, glad I wasn't missing something. You should be able to just add ! instead.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

@Forgind Forgind Jun 11, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<confusion>
I thought that was exactly what the bang was supposed to do. Ah, well.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ah, I see :) The bang is used to force Nullable Reference Types (the new hotness), but ?? x is used to convert a nullable Value Type to the underlying value type. Nullable value types (Nullable) was introduced way back in C# 2 in 2005

}
catch (InvalidProjectFileException e)
IMetadataContainer metadataContainer => metadataContainer.EnumerateMetadata(),
IItem<ProjectMetadata> iitem => iitem.Metadata?.Select(m => new KeyValuePair<string, string>(m.Name, m.EvaluatedValue)),
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks cleaner, but I'd curious about whether you can inline this to avoid allocating an IEnumerable. Probably not because of the null unless you wanted it really messy.

Also, do you need to unescape the value?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not sure about inlining

good question about unescaping, need to see whether the values on iitem.Metadata are already unescaped...


protected virtual void WriteItemSpec(string itemSpec)
{
WriteLinePretty(" " + itemSpec);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to check—this will not allocate the string of spaces every time, right?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it won't allocate the string literal, but it will allocate the string for the concatenated total, and it's terrible.

Fortunately we may have an intern this summer who may help look into rewriting the console loggers to avoid allocations.

}

ReadProjectConfigurationDescription(e.BuildEventContext, e.Items);
var projectKey = (e.BuildEventContext.NodeId, e.BuildEventContext.ProjectContextId);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can e.BuildEventContext be null here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No, BuildEventContext should always be set

OutOfProcNodeForwardCertainproperties is explicitly testing a feature where only some properties are forwarded from a different process on ProjectStartedEventArgs. When we move properties to ProjectEvaluationFinished the test loses meaning. So force it into the old behavior via an escape hatch.
The feature the test is testing is broken, but the test passes because it doesn't specify diag verbosity for its logger.

We will only log task outputs with diag verbosity.

Issue #6521 is tracking.
Issue #6518 is tracking.

More work is needed to understand the desired behavior of the system under test and then fix the test to test the desired behavior.
Call IEventSource4.IncludeEvaluationPropertiesAndItems()

OutputItems was pretty much duplicated in ParallelConsoleLogger. Unify with the base implementation and extract methods that need to be replaced by the derived type.

Support for reading project configuration description either from ProjectStartedEventArgs.Items or ProjectEvaluationFinishedEventArgs.Items.
Copy link
Member

@rainersigwald rainersigwald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks reasonable to me.

On the larger issue, I have a thought; I bet you can explain why it's bad. Could we log the data in both places, but only have the binlog record it at end-of-evaluation? And when replaying a binlog read it from the correlated end-of-evaluation to the ProjectStarted?

@KirillOsenkov
Copy link
Member Author

It's actually a reasonable thought. I don't see why it would be bad, perhaps it's worth implementing.

Remember though you'll only get the properties and items on ProjectStarted in the central node, since they are not serialized across. But it would achieve backwards compatibility (parity with what it used to be). Perhaps I should have built it this way to begin with!

The other question is combined with the other workarounds we've built, is it necessary anymore?

@KirillOsenkov
Copy link
Member Author

One thing that comes to mind is populating properties and items on ProjectStarted would decrease performance and increase allocations (since we would be walking the expensive data structures and copy-on-writing). So we'd lose some of those hard-won perf wins that we so tightly optimized.

@Forgind Forgind added the merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now. label Jun 26, 2021
@AR-May AR-May merged commit 78f0280 into main Jun 30, 2021
@KirillOsenkov KirillOsenkov deleted the dev/kirillo/loggers branch July 1, 2021 02:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

merge-when-branch-open PRs that are approved, except that there is a problem that means we are not merging stuff right now.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants