Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Dispose extension methods should not even be considered in pattern-based disposal #32767

Open
jcouv opened this issue Jan 25, 2019 · 1 comment
Labels
Area-Compilers Bug Concept-Diagnostic Clarity The issues deals with the ease of understanding of errors and warnings. help wanted The issue is "up for grabs" - add a comment if you are interested in working on it New Feature - Async Streams Async Streams New Language Feature - enhanced using Using pattern and declaration
Milestone

Comments

@jcouv
Copy link
Member

jcouv commented Jan 25, 2019

Currently, we bind x.Dispose() and reject the result if it is an extension. But we should not even consider extensions, to avoid diagnostics about ambiguities.

There is the same issue with binding GetAsyncEnumerator.

        [Fact]
        public void UsingPatternScopedExtensionMethodTest()
        {
            var source = @"
ref struct S1
{
}

namespace N1
{
    static class C2 
    {
        public static void Dispose(this S1 s1) { }
    }
}

namespace N2
{
    static class C3 
    {
        public static void Dispose(this S1 s1) { }
    }
}

namespace N3
{
    static class C4 
    {
        public static int Dispose(this S1 s1) { return 0; }
    }
}


namespace N4
{
    partial class C5
    {
        static void M()
        {
            using (S1 s = new S1()) // error 1
            {
            }
        }
    }
}
namespace N4
{
    using N1;
    partial class C5
    {
        static void M2()
        {
            using (S1 s = new S1()) // error 2
            {
            }
        }
    }
}
namespace N4
{
    using N3;
    partial class C5
    {
        static void M3()
        {
            using (S1 s = new S1()) // error 3
            {
            }
        }
    }
}
namespace N4
{
    using N1;
    using N3;
    partial class C5
    {
        static void M4()
        {
            using (S1 s = new S1())  // error 4
            {
            }
        }
    }
}
namespace N4
{
    using N3;
    namespace N5
    {
        partial class C5
        {
            static void M5()
            {
                using (S1 s = new S1())  // error 5 
                {
                }
            }
        }

        namespace N6
        {
            using N1;
            partial class C5
            {
                static void M6()
                {
                    using (S1 s = new S1())  // error 6 
                    { 
                    }
                }
            }
        }
    }
}";
            // Extension methods should just be ignored, rather than rejected after-the-fact. So there should be no error about ambiguities

            CreateCompilation(source).VerifyDiagnostics(
                // (37,20): error CS1674: 'S1': type used in a using statement must be implicitly convertible to 'System.IDisposable' or implement a suitable 'Dispose' method.
                //             using (S1 s = new S1()) // error 1
                Diagnostic(ErrorCode.ERR_NoConvToIDisp, "S1 s = new S1()").WithArguments("S1").WithLocation(37, 20),
                // (50,20): error CS1674: 'S1': type used in a using statement must be implicitly convertible to 'System.IDisposable' or implement a suitable 'Dispose' method.
                //             using (S1 s = new S1()) // error 2
                Diagnostic(ErrorCode.ERR_NoConvToIDisp, "S1 s = new S1()").WithArguments("S1").WithLocation(50, 20),
                // (63,20): error CS1674: 'S1': type used in a using statement must be implicitly convertible to 'System.IDisposable' or implement a suitable 'Dispose' method.
                //             using (S1 s = new S1()) // error 3
                Diagnostic(ErrorCode.ERR_NoConvToIDisp, "S1 s = new S1()").WithArguments("S1").WithLocation(63, 20),
                // (77,20): error CS0121: The call is ambiguous between the following methods or properties: 'N1.C2.Dispose(S1)' and 'N3.C4.Dispose(S1)'
                //             using (S1 s = new S1())  // error 4
                Diagnostic(ErrorCode.ERR_AmbigCall, "S1 s = new S1()").WithArguments("N1.C2.Dispose(S1)", "N3.C4.Dispose(S1)").WithLocation(77, 20),
                // (77,20): error CS1674: 'S1': type used in a using statement must be implicitly convertible to 'System.IDisposable' or implement a suitable 'Dispose' method.
                //             using (S1 s = new S1())  // error 4
                Diagnostic(ErrorCode.ERR_NoConvToIDisp, "S1 s = new S1()").WithArguments("S1").WithLocation(77, 20),
                // (92,24): error CS1674: 'S1': type used in a using statement must be implicitly convertible to 'System.IDisposable' or implement a suitable 'Dispose' method.
                //                 using (S1 s = new S1())  // error 5 
                Diagnostic(ErrorCode.ERR_NoConvToIDisp, "S1 s = new S1()").WithArguments("S1").WithLocation(92, 24),
                // (105,28): error CS1674: 'S1': type used in a using statement must be implicitly convertible to 'System.IDisposable' or implement a suitable 'Dispose' method.
                //                     using (S1 s = new S1())  // error 6 
                Diagnostic(ErrorCode.ERR_NoConvToIDisp, "S1 s = new S1()").WithArguments("S1").WithLocation(105, 28)
                );
        }
@gafter gafter added this to the 16.1 milestone Feb 18, 2019
@jcouv jcouv modified the milestones: 16.1, 16.2 Apr 23, 2019
@jcouv jcouv modified the milestones: 16.2, 16.3 Jun 25, 2019
@jcouv jcouv modified the milestones: 16.3, Compiler.Next Jul 11, 2019
@gafter gafter closed this as completed Nov 7, 2019
@gafter gafter added the Concept-Diagnostic Clarity The issues deals with the ease of understanding of errors and warnings. label Nov 7, 2019
@gafter gafter modified the milestones: Compiler.Next, Backlog Nov 7, 2019
@gafter gafter added help wanted The issue is "up for grabs" - add a comment if you are interested in working on it Bug labels Nov 7, 2019
@jcouv
Copy link
Member Author

jcouv commented Jun 10, 2024

This issue is still mentioned in code. Keeping open

@jcouv jcouv reopened this Jun 10, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Bug Concept-Diagnostic Clarity The issues deals with the ease of understanding of errors and warnings. help wanted The issue is "up for grabs" - add a comment if you are interested in working on it New Feature - Async Streams Async Streams New Language Feature - enhanced using Using pattern and declaration
Projects
None yet
Development

No branches or pull requests

2 participants