Warnings are not reported for repeated builds

[svick]

Steps to reproduce

1. dotnet new classlib

2. Change Class1.cs to:

   class C
   {
       async void M() {}
   }

3. dotnet build

4. dotnet build

Expected behavior

The second dotnet build prints the CS1998 warning, just like the first one.

Actual behavior

The second dotnet build does not print any warnings:

> dotnet build
Microsoft (R) Build Engine version 15.6.82.30579 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 87,92 ms for C:\code\tmp\hwapp\hwapp.csproj.
Class1.cs(3,16): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread. [C:\code\tmp\hwapp\hwapp.csproj]
  hwapp -> C:\code\tmp\hwapp\bin\Debug\netstandard2.0\hwapp.dll

Build succeeded.

Class1.cs(3,16): warning CS1998: This async method lacks 'await' operators and will run synchronously. Consider using the 'await' operator to await non-blocking API calls, or 'await Task.Run(...)' to do CPU-bound work on a background thread. [C:\code\tmp\hwapp\hwapp.csproj]
    1 Warning(s)
    0 Error(s)

Time Elapsed 00:00:02.37
> dotnet build
Microsoft (R) Build Engine version 15.6.82.30579 for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Restore completed in 81,94 ms for C:\code\tmp\hwapp\hwapp.csproj.
  hwapp -> C:\code\tmp\hwapp\bin\Debug\netstandard2.0\hwapp.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.96

Apparently, this happens because targets that are up to date are not re-run. Maybe warnings from previous builds could be saved somewhere and reported again when the target is skipped because it's up to date?

Environment data

dotnet --info output:

.NET Command Line Tools (2.1.300-preview2-008251)

Product Information:
Version: 2.1.300-preview2-008251
Commit SHA-1 hash: 94fd3fd

Runtime Environment:
OS Name: Windows
OS Version: 10.0.16299
OS Platform: Windows
RID: win10-x64
Base Path: C:\Program Files\dotnet\sdk\2.1.300-preview2-008251\

Microsoft .NET Core Shared Framework Host

Version : 2.1.0-preview2-26131-06
Build : b13a0d5c331f374afd35ded57b9a4b4ab128864c

---

Originally reported as https://github.com/dotnet/cli/issues/8722.

[petermorlion]

As mentioned in dotnet/cli#8722:

I think you want to use the --no-incremental option, i.e.:

dotnet build --no-incremental

This does, however, mean a full rebuild.

[rainersigwald]

The pure-MSBuild way to achieve dotnet build --no-incremental is msbuild /target:Rebuild which generally just means Clean;Build.

This is an entirely reasonable request but MSBuild's architecture makes it extremely difficult: the MSBuild engine itself does not have any state store to keep the previous build's warnings in. Its decision to run or not run a target can only look at the current state of files on disk in the current project's environment.

We've discussed building a place to store that sort of state before (for example #701) and always come to the conclusion that it was too big/risky a change for too little gain. There is some discussion of the complexity involved in that issue.

[pchilds]

I do not know of any build toolchains that store warning states, nor any reason why we should expect warnings to be repeated if there is not cause to rebuild the file.
I think this issue should be closed for the same reason as #5066

[richlander]

This seems like it should be moved to the docs repo and documented. I ran into this same UX and was confused.