Roslyn: Incorrect IDE0044 when NRTs are enabled, the class is generic, and the field is only set by a non-this reference

Created on 27 Sep 2019  路  17Comments  路  Source: dotnet/roslyn

Visual Studio 16.3.1 and 16.4p1

IDE0044 should not be reported.

class GenericClass<T>
{
    // IDE0044 Make field readonly
    private int field;

    public static void Method(GenericClass<T> instance)
    {
        instance.field++;
    }
}

Similarly:

class GenericClass<T>
{
    // IDE0044 Make field readonly
    private int field;

    public struct Helper
    {
        private readonly GenericClass<T> instance;

        public Helper(GenericClass<T> instance)
        {
            this.instance = instance;
        }

        public void Method()
        {
            instance.field++;
        }
    }
}

Csproj:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <LangVersion>latest</LangVersion>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>
Area-IDE Bug IDE-CodeStyle help wanted

All 17 comments

Neither cases repro for me on 16.4p1:

image

I'm reproing on 16.4p1. Did you press Ctrl+. on the line? The default visibility wouldn't show any visual.

To help me quickly see when it was present when I was trimming down the repro, I used this editorconfig:

root = true

[*]
dotnet_style_readonly_field = true:error

image

Crazy! And yes, i've got this feature turned on. I'm also on:

image

So sorry, I forgot that I had added <Nullable>enable</Nullable> to the project file. Updated at the top.

Yup. I repro now. Fascinating!

Tagging @mavasani . Note the necessity to update your project file. This didn't repro for me in a 4.7.2 project...

It repros for me on net472 (where I initially discovered it) as well as netcoreapp3.0.
E.g.

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <TargetFramework>net472</TargetFramework>
    <LangVersion>latest</LangVersion>
    <Nullable>enable</Nullable>
  </PropertyGroup>

</Project>

Tagging @333fred - seems to be another analyzer affected by https://github.com/dotnet/roslyn/issues/38195

Also tagging @chsienki who is currently investigating #38195

Note: if code has to be updated anyways to get the right nullable-behavior, then i'm far more inclined to say that our choices to try to expose nullable through these extra properties seems less useful. After all, if you still need to update to support nullable properly then we could have exposed nullable not through properties at all. In both cases people need to update to have their code work in the presence of nullable :)

This is marked 'help wanted' but it looks like it's linked to https://github.com/dotnet/roslyn/issues/38195. Is there something a community member could do to move this along?

Fixing #38195 should fix this issue. @chsienki @333fred do we know which release that fix is targeted for? If that is a some way out, then we can possibly put some workaround in the analyzer.

It was originally planned for 16.4, but it got put on hold because of all the ISymbol/Symbol separation work going on in the compiler. Should be a fairly easy fix once that work is finished though.

Still says up-for-grabs. Does that mean that the larger work is too far away?

That larger work is now landed. @chsienki what's the next step here then?

Was actually planning on starting #38195 on Monday :) aiming for 16.5 but we'll see on timelines if it makes it in.

Fixed via #41123

Was this page helpful?
0 / 5 - 0 ratings