janhoy commented on code in PR #4591:
URL: https://github.com/apache/solr/pull/4591#discussion_r3519828906
##########
solr/test-framework/src/java/org/apache/solr/util/SolrMatchers.java:
##########
@@ -40,17 +40,17 @@ public class SolrMatchers {
* @param <T> The type that the list being matched against will contain
*/
public static <T> Matcher<List<? extends T>> subListMatches(
- int fromIndex, int toIndex, Matcher<? super List<? super T>>
subListMatcher) {
+ int fromIndex, int toIndex, Matcher<Iterable<? extends T>>
subListMatcher) {
return new SubListMatcher<>(fromIndex, toIndex, subListMatcher);
}
public static class SubListMatcher<T> extends
TypeSafeDiagnosingMatcher<List<? extends T>> {
private final int fromIndex;
private final int toIndex;
- private final Matcher<? super List<T>> matchOnSubList;
+ private final Matcher<Iterable<? extends T>> matchOnSubList;
Review Comment:
Copilot is right: Claude's ECJ-3.46 fix over-narrowed the API. The old
signature (Matcher<? super List<? super T>>) accepted supertype-matchers like
Matcher<Iterable<?>> and Matcher<Object>; my invariant Matcher<Iterable<?
extends T>> rejected those. The suggested Matcher<? super Iterable<? extends
T>> keeps the ECJ fix while restoring that flexibility, at zero cost.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
