Age | Commit message (Collapse) | Author |
|
Until recently, we'd 'resolve' LUB (compound) types in val constructs by just taking the first one in the line of interfaces. The problem is, different versions of different compilers use different orderings. In an earlier commit, the eclipse impl gained a new algorithm that is more stable, e.g. by sorting on alphabet. now the javac side has the same algorithm.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
due to an invalid reference from src/utils to src/core.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Copy more Jackson annotation to the builder, also to @Singular methods
|
|
Add null check in copyTypeAnns
|
|
[SuperBuilder] fix IndexOutOfBounds (fixes #2407)
|
|
|
|
|
|
|
|
added some tests to confirm that lombok makes things static if needed.
|
|
Now generating checkerframework `@Pure` instead of `@SideEffectFree` where appropriate.
|
|
... unfortunately eclipse's val resolver is now very slightly worse in very exotic circumstances - spent about 4 hours trying to fix it, can't figure it out, let's move on.
|
|
|
|
|
|
lombok.noArgsConstructor.extraPrivate was incorrect
|