Create source-only filter package

[Youssef1313]

Fixes #15361

[Copilot]

Copilot encountered an error and was unable to review this pull request. You can try again by re-requesting a review.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 14 out of 14 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

[Youssef1313]

@copilot Create a new test project for the new package.

You MUST:

• Open a separate PR for that. Do not push to this PR.
• The new test project shouldn't reference the csproj. Instead, it should manually add the C# source files to Compile item.
• Write basic tests to validate the behavior of the APIs.

[Copilot]

@Youssef1313 I've opened a new pull request, #15641, to work on those changes. Once the pull request is ready, I'll request review from you.

[Youssef1313]

@nohwnd Would you like to change all namespaces in the source-only package?

[Youssef1313]

@copilot Please review this PR and add a comment with your findings. During review, ensure that all classes in the new package are internal and have embedded attribute (except when under #if IS_VSTEST_REPO).

[nohwnd]

Looks good. Consider adding integration test to Library.IntegrationTests that uses the package to ensure it works.

[Youssef1313]

@copilot add an integration test in Microsoft.TestPlatform.Library.IntegrationTests for this package.

[Youssef1313]

@copilot add an integration test in Microsoft.TestPlatform.Library.IntegrationTests for this package.

[Youssef1313]

@copilot Add an integration test in Microsoft.TestPlatform.Library.IntegrationTests for this package.

[Youssef1313]

@copilot Please add explicit #nullable enable in all files in C# code files in Microsoft.TestPlatform.Filter.Source.

[Copilot]

Pull request overview

Copilot reviewed 23 out of 24 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (4)

src/Microsoft.TestPlatform.Filter.Source/FilterExpressionWrapper.cs:58

• In the !IS_VSTEST_REPO build (i.e., when this code is embedded via the source-only package), the constructor does not validate filterString at all. In-repo it throws for null/empty via ValidateArg.NotNullOrEmpty, but out-of-repo it may fail later with less clear exceptions. Consider adding equivalent ArgumentNullException/ArgumentException validation in the else path to keep behavior consistent.
  src/Microsoft.TestPlatform.Filter.Source/FilterExpressionWrapper.cs:159
• In the !IS_VSTEST_REPO build, Evaluate does not check propertyValueProvider for null (the in-repo build does). If a consumer passes null, this will likely throw a NullReferenceException deeper in evaluation. Consider validating the delegate in the non-repo path too to provide a clear ArgumentNullException and keep behavior consistent.
  src/Microsoft.TestPlatform.Filter.Source/TestCaseFilterExpression.cs:90
• In the !IS_VSTEST_REPO build, MatchTestCase doesn’t validate propertyValueProvider for null, while the in-repo implementation does. Adding an ArgumentNullException check in the non-repo path would avoid null-derefs and keep behavior consistent between the in-repo and source-only-package builds.
  src/Microsoft.TestPlatform.Filter.Source/FilterHelper.cs:40
• The XML doc for Escape lists % as a character that will be escaped, but % isn’t included in SpecialCharacters/SpecialCharactersSet. Either update the documentation to match the actual escaped characters, or add % to the escaped character set if it is intended to be supported.

[Copilot]

Pull request overview

Copilot reviewed 23 out of 24 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (4)

src/Microsoft.TestPlatform.Filter.Source/Condition.cs:25

• using Microsoft.VisualStudio.TestPlatform.ObjectModel.Utilities; is unconditional, but under !IS_VSTEST_REPO this source-only code is intended to compile without referencing the ObjectModel assembly. Since no types from this namespace are used outside IS_VSTEST_REPO, wrap the using in #if IS_VSTEST_REPO (or remove it) to avoid compile failures for consumers.
  src/Microsoft.TestPlatform.Filter.Source/Condition.cs:135
• TPDebug.Assert(...) is referenced without a using Microsoft.VisualStudio.TestPlatform.Common; or full qualification. Since TPDebug lives in Microsoft.VisualStudio.TestPlatform.Common, this will not compile from within Microsoft.VisualStudio.TestPlatform.Common.Filtering. Consider switching to Debug.Assert (like FilterExpression.cs does) or fully qualifying the call.
  src/Microsoft.TestPlatform.Filter.Source/FilterExpression.cs:24
• using Microsoft.VisualStudio.TestPlatform.ObjectModel.Utilities; is unconditional. In the source-only package (!IS_VSTEST_REPO) this namespace may not exist in the consuming project, causing a compile error even if it’s unused. Wrap this using in #if IS_VSTEST_REPO (or remove it) to keep the embedded sources dependency-free.
  src/Microsoft.TestPlatform.Filter.Source/FastFilter.cs:120
• TPDebug.Assert(PropertyValueRegex != null); is referenced without bringing TPDebug into scope. Because TPDebug is in Microsoft.VisualStudio.TestPlatform.Common, this will not compile from this namespace. Prefer Debug.Assert(...) here (matching FilterExpression.cs) or fully qualify Microsoft.VisualStudio.TestPlatform.Common.TPDebug.

[Youssef1313]

@copilot Revert the file mode change here

[Copilot]

Pull request overview

Copilot reviewed 23 out of 24 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (4)

src/Microsoft.TestPlatform.Filter.Source/FilterExpressionWrapper.cs:58

• In the source-only (non-IS_VSTEST_REPO) build, the constructor no longer validates filterString. Passing null will currently lead to a NullReferenceException later, and empty strings may produce less actionable failures. Consider adding explicit argument validation in the non-repo path (e.g., if (filterString is null) throw ...; and/or empty check) so behavior is consistent and errors are clearer for package consumers.
  src/Microsoft.TestPlatform.Filter.Source/FilterHelper.cs:55
• In the non-IS_VSTEST_REPO build, Escape/Unescape no longer validate str. If a consumer passes null (e.g., from older code or with null-forgiveness), this will throw a NullReferenceException instead of a clear argument exception. Add an unconditional null check (or a non-repo check) so consumers get a consistent, actionable exception.
  src/Microsoft.TestPlatform.Filter.Source/TestCaseFilterExpression.cs:94
• For the source-only (non-IS_VSTEST_REPO) build, MatchTestCase doesn’t validate propertyValueProvider. A null provider will currently lead to failures deeper in evaluation rather than a clear argument exception. Consider adding explicit validation in the non-repo path to keep behavior consistent and error messages clearer for package consumers.
  src/Microsoft.TestPlatform.Filter.Source/FilterExpression.cs:343
• FilterExpression switched from TPDebug.Assert to Debug.Assert, which changes the assertion mechanism used in-repo. If TPDebug is the standard assertion helper in this codebase, consider keeping TPDebug.Assert under #if IS_VSTEST_REPO (and Debug.Assert or no assert for the source-only build) to stay consistent with existing diagnostics behavior.