compilation fails after switching from 2.5.6 to 2.6.1

[archieby]

We are using org.immutables value and org.immutables.vavr vavr-encodings in our project.
While versions 2.5.6 and 0.4.0 of that dependencies let the code compile as expected,
2.6.1 and 0.6.0 ones fail.

The only output we get is lots of cannot find symbol errors, which is not that helpful.

What might be causing this? Isn't version 2.6 backward compatible with 2.5?
Is there any way to get some additional information about the failure reasons?

[Stephan202]

@archieby if your get loads of seemingly irrelevant errors, it may be that the root cause is buried somewhere in there. And it may even be that it's not displayed, if there are more errors than are emitted by javac by default. In that case you'll have to increase that limit by specifying -Xmaxerrs. Just guessing here, but I hope this helps! (You'll still have to do a linear scan; no way around that afaik; sorry!)

[archieby]

thank you for your response, @Stephan202 .
I increased the limit as you suggested and looked through all the errors line-by-line.
Unfortunately only cannot find symbol ones there.
So it seems like the annotation processor does not do its job and version 2.6 is not 100% backward compatible with the 2.5 one.
Also tried adding compiler flags, suggested in the Troubleshooting section of the documentation. But unable to find anything meaningful there as well.
I think we'll stick to the 2.5 version for now as it works as expected and I see no way to find out why 2.6 does not

[Stephan202]

The error will have to be buried somewhere in the generated code; in case of a complex project/classpath setup it's not so trivial to compile the files one-by-one (if cyclic references don't prevent this outright, that is).

I'd suggest an alternative approach: generate the code with version 2.5 and 2.6, then diff the output directories. I'd expect that the 2.6 dir contains fewer files (as the annotation processor may not have completed all its rounds), but one of the files that was generated should contain a salient deviation. Once identified this ticket becomes more actionable from a bug fixing perspective :)

(@elucash, if you have some other neat debugging trick for this case, I'd love to hear it. My colleagues and I have hit similar issues, where a small error in our own code is crowded out by a mountain of other errors.)

[elucash]

@archieby thank you for reporting this. @Stephan202 thank you for detailed troubleshooting hints. I don't know what exactly caused the issue. It's definitely buried down there among other irrelevant errors, I can only hope you'll found the one. This is one of the major pain points with annotation processing in big (enough) modules is that some compilation error stops annotation processing and, as result, many classes are not generated along with many cannot-find-symbol errors which shadow the one caused this. 2.6.0 tried to maintain compatibility, but we cannot 100% guarantee it, especially if some breakage is due to a bug.
There are about 1 incompatible generated API changes I know of which can affect the small fraction of users using specific features:

1. If using de-pluralization feature, the varargs overload for addElements will not be de-pluralized anymore.

In addition, vavr encoding is still in it's 0.x versions and may also affected some incompatibility.

I would suggest trying to do what Stephan suggested to detect the changes in generated files or try to dissect/create minimal repro. Sorry for any inconveniences, nothing like that is really intended.