Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Prefer extension methods to intrinsic properties when arguments are p…
…rovided (#16032) * Initial look at issue meant to give priority to extension method if a property of same name exists and arguments are passed to it (assuming property is not a function value). Lots of things to sort out, this just takes care of the first layer of interaction between CheckExpression and NameResolution. Given impact on service / tooling, it is not clear that adding an entry in NameResolution.Item is the best choice, may reconsider into changing the return type of ResolveLongIdentInTypePrim instead. * bring it back to the simplest thing that could possibly work, and it seems to work on toy example. * Do not break all indexed properties in the world (that is, when there are no extension methods in scope). * Implementation: singling out indexer properties and properties with FSharpFunc as type. Tests: covering a bunch of allowed and disallowed shadowing cases. * Update LanguageFeatures.fs * minimize diff * do not break chained calls when there is an extension method with same name defined. * fantomas * actual chained calls should remain in the sample... * minimize diff * adding test for support of BCL System.Linq.Enumerable.Count() adding tests for before the feature on all the previous positive tests * (minor) formatting. * fixing partially applied function piped to ignore (fsharp/fslang-suggestions#1327) making .net framework tests fail * adjust baselines that differ between .net framework and .netcore * checking event handlers aren't affected by the feature * separate out Property and Method in DeclarationListInfo.Create, not clear how many things will be broken, but it does what is expected in VS * handling of static property * adjust DeclarationListInfo grouping logic to be specific to singling out extension method only, rather than the kind of all items (type and ctor method were being split, causing a test to fail and more entries in the completion list not related to accessing properties or extension methods). * add test checking the latest opened type extension takes precedence * minimize diff * minimize diff * Fix test (new error message) * fix bad merge on baseline file * better comments explaining the properties that are singled out / can't be overtaken by extension methods. * revisit DeclarationListInfo.Create to avoid regression where we'd show both event and extension method (only event can be called). The new logic 100% preserves the previous behaviour in absence of the particular condition we are interested for in RFC-1137. In case the condition for RFC-1137 hits, we partition the items for those to be split apart (property and extension methods), taking care of discarding items as we yield the expected tuples that correspond to each item and the rest is processed as it was originally. There are still probably loopholes with items showing up separated, but this would only impact if there are actually extension method and property with same name. * minimize diff * try to make fantomas happy, despite I don't see the difference * minimize diff * formatting & add a comment explaining usage of `createSublists` --------- Co-authored-by: Vlad Zarytovskii <vzaritovsky@hotmail.com>
- Loading branch information