Age | Commit message (Collapse) | Author |
|
|
|
process fixed a lot of type annoyance by adding more generics.
Also changed coding style from for/while/if/switch/catch/do ( expr ) {} to for (expr) {}, hence the changes _everywhere_.
|
|
does do something, but not enough. Still, we clear it, for the little good it does do.
|
|
installs, is a javac apt processor, and an agent, all at once.
|
|
|
|
|
|
script now works fine, even if your class has a @Data annotation.
|
|
|
|
names - that method was getting awfully long.
|
|
parameter was always receiving an ASTNode child. One of the methods actually gets an array of those, which isn't of course a subclass of ASTNode itself.
|
|
|
|
is no longer needed (our dep on lombok-patcher takes care of it), and the old EclipseTransformer system has been removed.
|
|
|
|
branch...
|
|
|
|
themselves via SPI. LinkedNOdeFinderTransformer is broken.
|
|
|
|
|
|
can't find it, it used to return -1, which is exceedingly useless and causes no end of bugs. Changed it to returning the start point of the search, which is a more useful fallback.
|
|
works now, no longer needed.
|
|
ond depending on your eclipse version, a long stack trace.
The problem boiled down to the JSP compiler used by the help system also being instrumented with lombok, but that's not exactly the environment lombok was expecting. Fixed by simply disabling lombok when the environments don't match what we expect. In the process, the instrumentation has been made a little more robust; multiple separate OSGi modules can all be instrumented now, instead of the first one winning.
|
|
especially the docs
on the lombok annotations in the lombok package need far more massaging.
Also added a feature to HandleSynchronized to not auto-generate the locker fields if
a specific name is provided (because, imagine you typoed those. You'd never find it!)
|
|
|
|
|
|
|
|
should run in java 1.5, so that an eclipse started on a 1.5 JVM will still run lombok.
|
|
|
|
its clearly eclipse-specific.
|
|
agent though I never tested it. I found a bug while browsing this code. fixed it.
|
|
parser, but also the CompilationUnitDeclaration class so we can store our AST in it for caching purposes.
|
|
|
|
Related to
8353911b1d3a8d59a07042976bb924a7eccb5d0d
|
|
|
|
the agent fixes the classpath all by its lonesome. Wahey!
|
|
method that handles method.invoke...
figured out that I accidentally added a second transform() method and that one was being found, and that somehow causes the problem.
The locating of the right transform method now also checks params. A 'method not found' is faaaaaaaaaaaaaaar easier to debug than picking the wrong one out of the lineup.
|
|
working due to
circular reference from the EclipseAST back to the CUD.
Now, patched a field into CompilationUnitDeclaration and using that, which works much better
together with the garbage collector.
|
|
occurs in the two most sane places:
- After the parser is done building a first rendition of the AST. (Usually lightweight and missing method bodies etc)
- After the parser is done taking such a lightweight AST and filling in the gaps.
Lombok then builts its own bidirectional and somewhat saner AST out of this, and hands this saner AST off for treatment. Things in the AST can be marked as 'handled'.
This seems to work swimmingly and should allow us to easily identify the annotations that are for us, and work our magic, no matter where they appear or on what, including
stuff inside method bodies.
|
|
|
|
- Split off the actual agent work into a separate src package in preparation for creating separate jars. Involved a lot of renaming
- Renamed TransformCompilationUnitDeclaration to TransformEclipseAST, as this class will also be transforming e.g. MethodDeclaration objects.
- Expanded the patching to also patch in transform calls when the parser fills in the Statement array for existing constructors, methods, and initializers.
- Redesigned the ClassLoaderWorkaround class quite a bit.
- Positioning should not work correctly ('jump to method' should jump to the getter annotation).
(Apparently, Clinit objects are always fully parsed in the original run, so no need to patch anything there).
|