.Net: [MEVD] Support MemoryExtensions.Contains in LINQ filters #13263
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
github-actions
bot
changed the title
westey-m
approved these changes
Oct 21, 2025
roji
changed the title
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This makes the provider filters compatible with C# 14 (see #12504, and dotnet/runtime#109757 on the runtime side). Note that this changes the entire repo to build with dotnet SDK 10.0 (rc2) - that's probably a good idea regardless to test with the latest, ensure compatibility etc. (but if this is problematic, let me know - it's only truly necessary for test coverage and can be reverted).
I'm not happy to have the implementation duplicated across the implementations: we have FilterTranslationPreprocessor for common LINQ filter preprocessing, and that would be the ideal place for this. However, rewriting MemoryExtensions.Contains to Enumerable.Contains would require doing MethodInfo.MakeGenericMethod which is incompatible with NativeAOT. I considered have a fake, non-invocable MethodInfo implementation to represent the closed generic MethodInfo to Enumerable.Contains (MethodInfo and Type are abstract, so we can create custom implementations compatible with NativeAOT), but that's quite involved/complicated. The better story here is probably to have a base class implementation for the provider filter processors, which recognizes specific patterns and dispatches to abstract handlers which specific implementations override; it would take care of recognizing the various Contains variants.
Note also that we already have duplication around Enumerable.Contains and List.Contains (the instance method), so this just adds another variant (for now). I'll think about cleaning this up.
Fixes #12504