-
Notifications
You must be signed in to change notification settings - Fork 4.1k
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
False positive for CS1503 with MSBuild 17.10, but not dotnet build #72098
Comments
@virzak, thanks for reporting this issue. In 17.10 and later, conversion of a collection expression to a type that implements For this particular example, |
In that case should IDE0028 shouldn't show up for cases like this. Here is a common scenario for context. Also why doesn't
|
@jcouv I'm also seeing this behavior, and it's a regression from 17.9. The WPF class |
@MadsTorgersen @KathleenDollard real world cases where this caused breaking changes. These examples seem very reasonable to be. They are places where a collection initializer would be legal. The original rules for collection expressions thus also were legal. But our recent restriction now breaks things. I don't love that we're breaking code, and that collection expressions don't live up to their original promise (a unified way to write collections that can handle the prior ways we had in the language). |
@aelij, this is the expected behavior in 17.10 with the breaking change.
It looks like the .NET 9.0.100-preview.1 SDK is using an earlier commit of Roslyn, and does not include this change. |
Started an internal discussion on this topic. Will escalate this to the LDM asap. |
@cston The problem here is that that strict rules cuts out many normal collection types that were not generic. They are IEnumerable (The normal iteration type of the time), but have strongly typed Add methods so people wouldn't add inappropriate elements to them. These types worked fine with collection-initializers, and the initial shipping form of collection-expressions. Unfortunately, requiring that In the internal email i've proposed that if the type implements |
Since nongeneric collections often indicated element type through the indexer property type, that would be the moral equivalent of determing the |
@jnm2 I like that idea. I Will raise it internally! |
@jnm2 I've sent out that idea. Note: i prefer your idea a lot as:
-- The open question, in my mind, is whether we are going the route of saying:
In other words, both approaches would allow this to work. But each would be saying something quite different about the element type. Personally, i prefer '2' as it really seems to convey the type information that these types were trying to convey in the pre-generics world. Tagging @RikkiGibson as well. |
And @333fred :) |
@cston Thanks for the explanation. BTW that document is not very visible. It would be helpful to publish such breaking changes under https://learn.microsoft.com/en-us/dotnet/core/compatibility/8.0 |
See dotnet/roslyn#72098 (comment) Add links from the .NET breaking changes articles to the corresponding C# compiler breaking changes articles.
@aelij FYI, a link is being added in dotnet/docs#39681 |
* Add links to C# compiler breaks See dotnet/roslyn#72098 (comment) Add links from the .NET breaking changes articles to the corresponding C# compiler breaking changes articles. * fix warnings. * fix links again. * respond to feedback.
This used to work in versions prior to 17.10. Might be related to dotnet/sdk#38777
Version Used: 17.10.0-preview-24101-01+07fd5d51f
Steps to Reproduce:
This code compiles fine with
dotnet build
, but notmsbuild
Diagnostic Id: CS1503
Expected Behavior:
Actual Behavior:
The text was updated successfully, but these errors were encountered: