dotnet / roslyn-analyzers

MIT License
1.58k stars 463 forks source link

Microsoft.CodeAnalysis.PublicApiAnalyzers fails to read NRT annotations #3260

Closed RussKie closed 4 years ago

RussKie commented 4 years ago

Analyzer package

Microsoft.CodeAnalysis.PublicApiAnalyzers

Package Version

3.0.0-beta2.20077.2

Diagnostic ID

RS0017

Repro steps

  1. clone the repo and build
    git clone https://github.com/dotnet/winforms.git
    cd .\winforms
    git checkout 5e41a27c9eb22221642065e57ef427e91ae61e38
    .\build.cmd -c Debug
  2. Observe that the build fails: error RS0037: PublicAPI.txt is missing '#nullable enable', so the nullability annotations of API isn't recorded.
  3. Checkout the next commit that adds the requested decoration (or add it yourself)
    git checkout d212876c475cf4c78d7dc3027d856070f7d0f28e
    .\build.cmd -c Debug
  4. Observe that the build now fails with: error RS0036: Symbol 'Equals' is missing nullability annotations in the declared API.
  5. Checkout the next commit that updates the requested annotations via Visual Studio auto-fix (or update the annotations yourself via Visual Studio)
    git checkout 1b5ffb18ba33cad3b48d69961089c11df68847a1
    .\build.cmd -c Debug
  6. See that the build still fails to load the updated annotations

Expected behavior

Actual behavior

image image

mavasani commented 4 years ago

Tagging @jcouv

jcouv commented 4 years ago

I've encountered this situation at some point in the roslyn repo. As far as I could tell, it was due to two different versions of the analyzer being used in different contexts (one in the build from IDE and one from build from command-line). I'd try to get a structure log from the scenario where the last errors occur and double-check what binaries/version of the analyzer is being used.

RussKie commented 4 years ago

@jcouv feel free to ping me on teams if you need more info.

mavasani commented 4 years ago

@jcouv @RussKie has this been resolved?

jcouv commented 4 years ago

Not yet. I was away for a few days. I'm still trying to debug the failure. I've set up my local machine to repro with a locally built PublicAPI analyzer package, and instrumented the code with Debugger.Launch(), but unfortunately that's not prompting me to attach a debugger... :-(

jcouv commented 4 years ago

Let me know if you have any tips or other ways to debug this sort of issue.

jcouv commented 4 years ago

After running build.cmd, I looked at the binlog file and extracted the csc command-line to repro the issue.

Interestingly, I noticed that changing the version of the csc binary I used caused the issue to get resolved.

For instance, this one works, using latest compiler bits (built locally): D:\repos\winforms\.dotnet\dotnet.exe exec "D:\repos\roslyn\artifacts\bin\csc\Debug\netcoreapp3.1\csc.dll" /noconfig @repro.rsp

This one also works (recent compiler bits, part of VS 16.6p1): "C:\Program Files (x86)\Microsoft Visual Studio\2019\IntPreview\MSBuild\Current\Bin\Roslyn\csc.exe" /noconfig @repro.rsp

But this one fails (complaining about declared API): D:\repos\winforms\.dotnet\dotnet.exe exec "D:\repos\winforms\.dotnet\sdk\5.0.100-alpha1-015536\Roslyn\bincore\csc.dll" /noconfig @repro.rsp

Looking at D:\repos\winforms\.dotnet\sdk\5.0.100-alpha1-015536\Roslyn\bincore\csc.dll I see that it is version 3.4 of the compiler, compared to C:\Program Files (x86)\Microsoft Visual Studio\2019\IntPreview\MSBuild\Current\Bin\Roslyn\csc.exe which has version 3.6

The implementation of nullability was only completed/shipped in version 3.5 of roslyn (corresponding VS 16.5), so I suspect this is the problem. To use #nullable enable in the publicAPI file, I think that you need to use version 3.5 of the compiler. At least, I verified using version 3.6, which works for sure

I'm not sure how to update the version of roslyn used in the winforms repo, as I didn't find an entry in eng\Versions.props. Do you know how to do it?

RussKie commented 4 years ago

Thank you @jcouv for the investigation.

Now when you explained it, the results are making sense, Windows Forms is pinned a very old version of Microsoft.NETCore.App due to a blocking dependency in WPF on a C++ toolset (which is being worked on by @tgani-msft et al).

@vatsan-madhavan @mmitche @AdamYoblick do you know if it is possible to use a newer version of Roslyn while remain pinned to Microsoft.NETCore.App?

jcouv commented 4 years ago

@jaredpar You mentioned there is a setting UseSomethingSomethingToolset to reference a specific version of roslyn rather than that in the SDK. What is the name of that setting? Would you recommend it in this scenario?

vatsan-madhavan commented 4 years ago

You mean using a newer version of Roslyn to build dotnet/winforms? Maybe @tmat would know.

My guess is that you'll have to get into the weeds of how build-tooling works and override it yourself.

See https://github.com/dotnet/arcade/blob/master/Documentation/InfrastructureEcosystemOverview.md

RussKie commented 4 years ago

Looks like we are unable to update to the latest runtime - blocked by by the C++ toolset issue that blocks WPF.

jcouv commented 4 years ago

@RussKie Any progress? I'm not sure we want to keep this issue opened on analyzers at this point.

RussKie commented 4 years ago

I think it is done. Thank you