Branch: refs/heads/pmd/7.0.x
Home: https://github.com/pmd/pmd
Commit: 3cc4313654560fa85be36da7f9c49d0aeaff6f43
https://github.com/pmd/pmd/commit/3cc4313654560fa85be36da7f9c49d0aeaff6f43
Author: Clément Fournier <[email protected]>
Date: 2020-10-13 (Tue, 13 Oct 2020)
Changed paths:
M
pmd-java/src/main/java/net/sourceforge/pmd/lang/java/types/JIntersectionType.java
M pmd-java/src/main/java/net/sourceforge/pmd/lang/java/types/Lub.java
M pmd-java/src/main/java/net/sourceforge/pmd/lang/java/types/TypeOps.java
M pmd-java/src/main/java/net/sourceforge/pmd/lang/java/types/TypeSystem.java
M pmd-java/src/test/kotlin/net/sourceforge/pmd/lang/java/types/GlbTest.kt
Log Message:
-----------
Give up trying to prune incompatible types from LB
In the general case this is possible but complex,
I don't want to introduce that kind of complexity yet.
The complex case is when you have a diamond like
List<? extends Number> & Collection<Integer>
If we try to remove incompatible bounds, we have to
minimize aggressively to `List<Integer>` if we want
to preserve associativity properties. This looks simple
but in general requires finding the most specific type
arguments (comparing Collection<? extends Number> and
Collection<Integer>), then an inversion function that
maps this Collection<Integer> type back to List<Integer>.
In this case
`forall T. List<T> <:Collection<T>`
but there could be an arbitrary transform F st. Sub<X1..Xn> <: Sup<F(X1..Xn)>,
which must be inverted.
I don't think it's worth the effort for now. This kind
of inconsistencies may only be present in user-created
intersections anyway, or invalid programs
_______________________________________________
Pmd-commits mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pmd-commits
