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
Completion sugests items that do not satisfy generic constraint #39689
Comments
That does not look like native VS IntelliSense. Is that Resharper? |
@ivanbasov This sounds like #37780 but was reported on 16.5 internal preview. |
@jinujoseph this has been a reoccurring issue and would be nice to fix. We first saw this in 16.3, then it seemed like it was fixed, now it's reoccurring again in 16.5. |
This bug causes some extension methods from Azure SDKs to be displayed in IntelliSense for every type. We have Azure customers being confused and filing issued about it: Azure/azure-sdk-for-net#15608 Is there any way we can prioritize this issue as it has a very real-world impact on customers? |
@genlu ptal. |
This seems to be a compiler issue. public interface ISomeInterface<T>
{ }
public static class Ext
{
public static bool SomeExtMethod<T1, T2>(this T1 builder, T2 x)
where T1 : ISomeInterface<T2>
{
return true;
}
}
public class Bar
{
void M(string[] s)
{
s.$$
}
} |
This is by design. We cannot check constraints that depend on type parameters that cannot be inferred from |
Adding in a bit of history to issue. The idea of how to handle extension methods and dependent type parameters first came up in #11166. This was based on user feedback and the decision was to ignore dependent constraints when considering extension methods. The motivating scenario is very similar to the one laid out here but with
The behavior of including these methods got reverted during the C# 7.3 development as a part of implementing the Note: the scenarios are all a bit different in the specific details but they are all essentially oscillating on the idea of how we should handle constraints in extension method reduction. Particularly when they are not fully inferable when dotting off the receiver. Overall though this is a case where the compiler is being asked to operate with imperfect information. Hence we end up with a heuristic vs. more definitive behavior. There were some discussions about how we could tune this to make this case better without breaking the existing cases by special casing interfaces to a degree. This is not a trivial fix though and it's unclear how grokable this is going to be for end users where as the behavior today is fairly easy to explain. Reactivating the issue for the purpose of exploring that idea though and seeing where we end up. Note: readers should note that overall this API pattern is decidedly unfriendly for VB users as they must resort to explicit type parameters here. |
Version Used: Version 16.5.0 Preview 1.0 [29501.166.master]
Steps to Reproduce:
Azure.Storage.Blobs
Nuget packageargs.
Expected Behavior:
Extension methods that don't satisfy the generic constraint are not shown.
Actual Behavior:
AddBlobServiceClient is shown
The text was updated successfully, but these errors were encountered: