AV1568: `in` should be allowed

[Christopher-Marcel Esser]

Analyzer

AV1568: Don't use parameters as temporary variables

Repro steps

Pass a parameter into a method call as in parameterName.

Expected behavior

AV1568 should not be raised because the in parameter modifier forbids modification, thus it is a simple usage of the parameter.

Here is the documentation explaining the modifier:

It is like the ref or out keywords, except that in arguments cannot be modified by the called method. Whereas ref arguments may be modified, out arguments must be modified by the called method, and those modifications are observable in the calling context.
https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/in-parameter-modifier

The documentation for AV1568 is also wrong: It should only list ref and out being forbidden. Additionally it could perhaps specifically mention in being allowed as it is unable to modify the parameter.

Actual behavior

AV1568 is raised for in parameter usage.

[Bart Koelman]

Hi @bddckr, thanks for your detailed report. I am aware of the in modifier. However I do not understand how that applies to AV1568. To illustrate, the next example does not cause any warnings on my system:

        static void Test(in bool recurse)
        {
            if (recurse)
            {
                int argument = 100;
                Method(in argument);
            }
        }

        static void Method(in int parameterName)
        {
            bool recurse = false;
            Test(in recurse);
        }

Can you provide some example code that demonstrates the problem?
Also, what version of CSharpGuidelinesAnalyzer do you use? And what version of Visual Studio?

[Christopher-Marcel Esser]

Oh sorry I totally finished this report without the additional details I still wanted to add before submitting! 😅

I can confirm your sample doesn't raise the diagnostic for me either.

Minimum sample to reproduce:

// AV1568	The value of parameter 'a' is overwritten in its method body.
static void M(bool a)
{
    N(in a);
}

static void N(in bool b)
{
    // Do something with `b`.
}

So the issue is only with passing the bool a into in bool b there. As soon as you change M to in bool a, too, the diagnostic isn't raised. I can't do that since M is implementing an interface method I'm implementing.

I'm using

• CSharpGuidelinesAnalyzer 3.2.0
• Visual Studio 16.3.0 Preview 2.0

[Bart Koelman]

Can you provide a sample solution? The thing is, I cannot reproduce the warning in the latest stable VS version, nor in the preview that you are using.

[Bart Koelman]

Update: I was looking for warnings, but this analyzer reports at info level, which is why I missed it. So I can reproduce the problem now. Unfortunately it is a known bug in Roslyn.

[Christopher-Marcel Esser]

I see, thanks for being so diligent!

Next time I'll ensure to include that I set the rule to be of Error severity 😄 I can see how that was confusing! Perhaps the bug issue template could be updated to ask about it, including the version of the analyzer in use and Visual Studio's. But that's for another issue 😉

[Bart Koelman]

Thanks for the suggestions. But usually I can reproduce once I get a code snapshot, so I don't want to raise the bar for submitting bugs unnecessary. The severity I will keep in mind from now on. For structs, this rule already uses a custom assignment analyzer, but I expect it fails on corner cases and it requires updates on language changes (for example https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/null-coalescing-assignment). So for classes I prefer to keep relying on roslyn flow analysis.

[Bart Koelman]

Closing this issue, because the bug is in another repo.