@dmgandini I think that it´s a conflict between two analyzers: ReadonlyFieldAnalyzer and NoPrivateReadonlyFieldAnalyzer. For example, this code:

public class Foo
    {
        private int i = 0;
    }

It´s analyzed by both analyzers, but only ReadonlyFieldAnalyzer create diagnostic and trigger fix, although there is a test that says that this is not an error for analyzer (PrivateFieldWithAssignmentOnDeclarationCreatesNoDiagnostic). Test is using only NoPrivateReadonlyFieldAnalyzer, but executing project and creating a code, both analyzers are running.

Can you check this ?

@carloscds It is the expected behavior as far as I understood the issue.
The ReadonlyFieldAnalyzer performs tests against private fields, because it needs to search in a single type.

The NoPrivateReadonlyFieldAnalyzer will chase the other modifiers, because it depends to search through other types. On compilation time.

So its normal one analyser be trigged and the another one be quiet, they have different views of same problem and both are correct.

You can argue that NoPrivateReadonlyFieldAnalyzer could do the both roles if CanBecameReadOnlyField method be changed, but It is healthy to keep two analysers because:

NoPrivateReadonlyFieldAnalyzer performs tests only on compilation and its not quite common to have a public fields exposed on types.

ReadonlyFieldAnalyzer does not depend on any compilation and its a common scenario.

@dmgandini The diagnostic id is wrong, number 74 was assigned to another issue. @carloscds be careful to check the wiki. I have updated the wiki so fix this: https://github.com/code-cracker/code-cracker/wiki/DiagnosticIds/_compare/47cbc9af8941a664f3ffb85c9d599b4976b37ec1...d1353edefb9a428e43955defd731309bf04346cf

I am not sure if the best implementation here is to the analyzis manually. Probably it would be better to use SemanticModel.AnalyzeDataFlow. I will open an issue to review this.

@dmgandini AnalyzeDataFlow is not working for out/ref parameters. So I will leave it as is by now.

Another issue: I have disabled the analyzer for another reason: as it runs very late on the compilation stage (only when the compilation ends), it might happen that a field no longer can be made readonly, and the diagnostic remains. This is a problem, as the user might run the code fix, and that might actually break the code.
I am going to open a bug to work on the code fix for that specific case. The diagnostic actually has to run again before the code fix is done, and maybe not offer a fix at all if the user has changed something and the compilation end event did not run yet.
BTW, any idea on how to solve this problem?

Also, I have changed the registration of the compilation end to happen on the compilation start. See this line: