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

C# compiler should report CS0121 consistently between VS2017 and VS2019, when ambiguous call is detected in named method syntax #35361

Closed
jimmyheaddon opened this issue Apr 30, 2019 · 3 comments
Labels
Area-Compilers Question Resolution-By Design The behavior reported in the issue matches the current design

Comments

@jimmyheaddon
Copy link

jimmyheaddon commented Apr 30, 2019

Version Used: VS2017 Enterprise (15.9.11) and VS2019 Enterprise (16.0.2)

Steps to Reproduce:

  1. Create a .NET Standard 2.0 class library
  2. Reference NuGet package System.Threading.Task.Dataflow v4.9.0
  3. Replace Class1.cs contents with
namespace CompilationAmbiguityExample
{
    using System.Threading.Tasks.Dataflow;

    public class Class1
    {
        public Class1()
        {
            // NOTE: This line fails to compile in VS2017 and the 2017 hosted agents for Azure DevOps, but succeeds in VS2019 or the 2019 hosted agents for Azure DevOps.
            // ERROR: Error CS0121  The call is ambiguous between the following methods or properties: 'TransformBlock<TInput, TOutput>.TransformBlock(Func<TInput, TOutput>)' and 'TransformBlock<TInput, TOutput>.TransformBlock(Func<TInput, Task<TOutput>>)'    CompilationAmbiguityExample C:\Git\AppEng\CompilationAmbiguityExample\CompilationAmbiguityExample\Class1.cs	12	N/A

            var ingestionPipelineNonAmbiguous = new TransformBlock<IDataflowMicroservicePayload, IDataflowMicroservicePayload>(this.OnPayloadReceived);

            // FIX: Changing to an explicit lambda syntax fixes the error in VS2017
            // var ingestionPipeline = new TransformBlock<IDataflowMicroservicePayload, IDataflowMicroservicePayload>(payload => this.OnPayloadReceived(payload));
            // OR: Change to this explicit cast, which also works
            // var ingestionPipeline = new TransformBlock<IDataflowMicroservicePayload, IDataflowMicroservicePayload>((Func<IDataflowMicroservicePayload, IDataflowMicroservicePayload>)this.OnPayloadReceived);
        }

        private IDataflowMicroservicePayload OnPayloadReceived(IDataflowMicroservicePayload _)
        {
            return new DataflowMicroservicePayload();
        }

        private class DataflowMicroservicePayload : IDataflowMicroservicePayload
        {
        }

        private interface IDataflowMicroservicePayload
        {
        }
    }
}

  1. Compile in VS2017 Enterprise
  2. Compile in VS2019 Enterprise
  3. VS2017 will have thrown a CS0121 compilation exception, whereas VS2019 won't have
  4. Changing from the Named method syntax to either the lambda or cast suggestions used in the "FIX" comments above, does resolve the error in VS2017

Expected Behavior: Both VS2017 and VS2019 either report (or handle) the "ambiguous" declaration the same, when using Named method syntax

Actual Behavior: VS2019 Enterprise (and hosted 2019 build agent in Azure DevOps) compiles successfully, but VS2019 Enterprise (and hosted 2017 build agent in Azure DevOps) throws a compilation error of CS0121 The call is ambiguous between the following methods or properties: 'TransformBlock<TInput, TOutput>.TransformBlock(Func<TInput, TOutput>)' and 'TransformBlock<TInput, TOutput>.TransformBlock(Func<TInput, Task<TOutput>>)'

This is likely shoddy architecture, but regardless of that, VS2017 and VS2019 compilers should really behave consistently, between the 2 versions.

I've tried the following Dataflow versions, which all exhibit the same behaviour:

  • 4.7.0
  • 4.9.0
  • 4.10.0-preview4.19212.13
@jimmyheaddon jimmyheaddon changed the title C# compiler should report CS0121 when ambiguous call made in VS2019, as per VS2017. C# compiler should report CS0121 in both VS2017 and VS2019, when ambiguous call is made Apr 30, 2019
@jimmyheaddon jimmyheaddon changed the title C# compiler should report CS0121 in both VS2017 and VS2019, when ambiguous call is made C# compiler should report CS0121 consistently between VS2017 and VS2019, when ambiguous call is made Apr 30, 2019
@jimmyheaddon
Copy link
Author

If it's useful, I've saved off the build Output (diagnostic verbosity) for both VS2017 and VS2019, which I can provide. I've opted not to attach them publicly, as they contain personal and potential sensitive organisation information.

@jimmyheaddon jimmyheaddon changed the title C# compiler should report CS0121 consistently between VS2017 and VS2019, when ambiguous call is made C# compiler should report CS0121 consistently between VS2017 and VS2019, when ambiguous call is detected in named method syntax Apr 30, 2019
@svick
Copy link
Contributor

svick commented Apr 30, 2019

I believe this is the expected behavior. What happens is:

  1. C# 7.3 introduced "Improved overload candidates" (Champion "Improved overload candidates" (15.7) csharplang#98), which means code like yours that didn't previously compile does compile now.
  2. Latest updates of both major versions of VS support C# 7.3, but the default for VS 2017 is still C# 7.0.

This is why your code compiles in VS 2019 (because the code is compiled as C# 7.3), but produces an error in VS 2017 (because the code is compiled as C# 7.0).

If you want to make your code behave consistently, I think you should explicitly specify language version for your project. Use 7.3 if you want it to work consistently. Use 7.0 (or 7.1, or 7.2) if you wanted it to fail consistently, for some reason.

@jimmyheaddon
Copy link
Author

Thanks for the quick response @svick, I hadn't considered that! I'm happy to close this, if you're confident it's expected behaviour? :)

@gafter gafter added Area-Compilers Question Resolution-By Design The behavior reported in the issue matches the current design labels Apr 30, 2019
@gafter gafter closed this as completed Jul 12, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Area-Compilers Question Resolution-By Design The behavior reported in the issue matches the current design
Projects
None yet
Development

No branches or pull requests

3 participants