Output illink messages without --verbose

[marek-safar]

We need to propagate msbuild verbose level (-verbosity:level option) into illink.

The proposed mapping between msbuild verbosity and MessageCategory

q[uiet] >= MessageCategory.Error (not sure about this one)
d[etailed] >= MessageCategory.Info
diag[nostic] >= MessageCategory.Diagnostic

This should be done for illink task only, the command line interface for illink should still use -v to print everything

@vitek-karas how do you plan to use warning? If we go with an explicit -nowarn option we would need to expose that on VS UI.

[vitek-karas]

Errors and Warnings should be reported always, even on quiet mode.

I wonder if we could somehow hook into the <NoWarn>, for example NuGet seems to be part of it as it's valid (and works) to specify <NoWarn>NU.... But this need investigation.

[marek-safar]

Errors and Warnings should be reported always, even on quiet mode.

I agree but that means we need a solution to suppress the warnings which also means to add UI to all VS-es for that. NuGet seems to allow that on package level which I think is not we want.

[vitek-karas]

Not sure about the UI for this, but it apparently can be specified globally as well: https://github.com/microsoft/msbuild/blob/a4878e187d0640ee79b7cdc12c640f68e28a326b/Directory.Build.props#L54

[vitek-karas]

This already has VS UI

Ideally linker would somehow integrate with that. We might even want to choose warning levels and so on. That said, we should definitely discuss this with whoever "owns" this UI/property to make sure we don't break something else with such approach.

[marek-safar]

Oh, I didn't know they hacked into compiler warnings. This looks like prior art for us then which we can "just" use if we validate that the NU* prefix is not embedded anywhere in VS.

[sbomer]

I don't think we should feed in the MSBuild verbosity anywhere - rather, we should just make sure that our task uses stdout/stderr in a reasonable way, and formats warnings/errors how MSBuild expects them when it's being run from the task.

ToolTask is already designed to assign reasonable MSBuild MessageImportance to various bits of output, in a way that makes sense with the default logger (which treats MessageImportance according to https://docs.microsoft.com/en-us/visualstudio/msbuild/obtaining-build-logs-with-msbuild?view=vs-2019#verbosity-settings). For us that means:

• Outputs that are formatted like warnings or errors (https://docs.microsoft.com/en-us/archive/blogs/msbuild/msbuild-visual-studio-aware-error-messages-and-message-formats) show up at any MSBuild verbosity (quiet/minimal/normal/detailed/diagnostic)
• The command-line invocation of the tool gets MSBuild MessageImportance.High, which shows up in minimal/normal/detailed/diagnostic
• Stderr gets MSBuild MessageImportance.Normal, which shows up in normal/detailed/diagnostic
• Stdout gets MSBuild MessageImportance.Low, which shows up in detailed/diagnostic

The importance of stdout/stderr can be changed if we prefer a different behavior. IMO we might want to make Stdout have MessageImportance.Normal, so that it is visible with "normal" verbosity (with the default importance of Low, it shows up only at detailed+, in a dark grey that is hard to read against a black background).

We should then make sure that stdout and stderr by default only show messages we care about, and an extra property (say TrimmerVerbosity) can tell the tool to include more output.

[sbomer]

Also, apparently MSBuild intentionally doesn't provide a way to get the current verbosity

[marek-safar]

Stderr gets MSBuild MessageImportance.Normal, which shows up in normal/detailed/diagnostic
Stdout gets MSBuild MessageImportance.Low, which shows up in detailed/diagnostic

This makes sense to me, we should tweak the msbuild output to respect that. Does it also mean the error/warning should go to stderr?

show messages we care about, and an extra property (say TrimmerVerbosity) can tell the tool to include more output.

Please don't, that would complicate things with no good reason

[vitek-karas]

I agree that we should not have any logging which doesn't fall directly into one of the MSBuild categories. If there's a need for a more detailed trace, we can introduce a separate solution which produces this information to a file. But the existing support for dependency tracing is kind of already that. We could always extend that if needed.