Bug 8388 - Declaration conflict check differs between mono MCS and MS CSC
Summary: Declaration conflict check differs between mono MCS and MS CSC
Alias: None
Product: Compilers
Classification: Mono
Component: C# ()
Version: unspecified
Hardware: PC Windows
: --- normal
Target Milestone: ---
Assignee: Marek Safar
Depends on:
Reported: 2012-11-13 19:27 UTC by Brett van Swelm
Modified: 2012-11-20 05:34 UTC (History)
1 user (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Brett van Swelm 2012-11-13 19:27:58 UTC
Declaration conflict check differs between mono MCS and MS CSC.

With "D:\Applications\Mono-2.11.4\bin" and
"C:\Windows\Microsoft.NET\Framework\v4.0.30319" in the path on my Windows 7

===== ChildBlock.cs =====
using System;

public class Something {
    public void DoSomething(Action<String> Callback) {}

public class ChildBlock {
    public Something x = new Something();
    public void DoNothing(Something p) {}

    protected void Test(int p) {
        if (p != 1) {
            var x = new Something();
        if (p != 2) {
            x.DoSomething((String) => {});
    public static void Main(String[] args) {}
===== end =====

This actually looks like a bug in CSC. Based on
http://msdn.microsoft.com/en-us/library/444w1dwy(v=vs.80).aspx I would not
expect CSC to accept this code either. CSC fails with the same error if the
lamda expression related call within the p != 2 block is removed. Assuming the
presence of the lamda expression isn’t supposed to suppress this check, it
looks like CSC is confused and MCS is correct, however if compatibility
with CSC is a goal this may be worth fixing.

$ csc ChildBlock.cs
Microsoft (R) Visual C# Compiler version 4.0.30319.17929
for Microsoft (R) .NET Framework 4.5
Copyright (C) Microsoft Corporation. All rights reserved.

$ mcs ChildBlock.cs
ChildBlock.cs(18,19): error CS0135: `x' conflicts with a declaration in a child
ChildBlock.cs(13,17): (Location of the symbol related to previous error)
Compilation failed: 1 error(s), 0 warnings


Brett van Swelm | Senior Engineer
Coverity | 185 Berry Street | Suite 6500, Lobby 3 | San Francisco, CA 94107
The Leader in Development Testing
Read our profile in Forbes, Coverity Gets Code Right 25% Faster
Comment 1 Marek Safar 2012-11-19 11:10:04 UTC
This is interesting case but I am not sure yet what is the correct behaviour for now.

Simplified test case.

using System;

public class Test
    Test x;

    void Foo()
            string x = "dd";

            x = null; // Commenting out this line causes expected CS0135 compiler error with csc

        x = new Test ();
    public static void Main () {}

It compiles without error unless you comment out line with x = null. Looking at the C# spec I can only see following definition which seems to be ignored in this case.

For each occurrence of a given identifier as a simple-name in an expression or declarator, every other occurrence of the same identifier as a simple-name in an expression or declarator within the immediately enclosing block (§15.2) or switch-block (§15.7.2) shall refer to the same entity.
Comment 2 Marek Safar 2012-11-20 05:34:16 UTC
Microsoft confirmed it's a bug in their code and should be fixed in Roslyn version of their compiler.