Age | Commit message (Collapse) | Author |
|
annotation @NotNull/@NonNull/@Nullable that is copied over by @Getter should no longer be causing the David Lynch bug.
|
|
|
|
Conflicts:
src/lombok/eclipse/handlers/HandleData.java
src/lombok/eclipse/handlers/HandleEqualsAndHashCode.java
src/lombok/eclipse/handlers/HandleSetter.java
src/lombok/javac/handlers/HandleData.java
src/lombok/javac/handlers/HandleEqualsAndHashCode.java
src/lombok/javac/handlers/HandleSetter.java
|
|
|
|
|
|
annotation
The constructor will test for null-values
The constructor and static constructor will copy the NonNull annotations from the fields
|
|
new annotation, @EqualsAndHashCode.
Addresses issue #8
|
|
has now moved from HandleData to the new HandleToString.
|
|
|
|
hitting 'find callers' on a @Data annotation should find callers of the (static) constructor.
Right now it'll find callers to the *static* constructor ONLY. Letting it find callers of the public constructor if there is no static constructor just doesn't work.
|
|
|
|
the class would generate errors regarding IllegalArgumentException in setSourcePosition in ASTNode.
|
|
Also fixed a bug in javac's toString() generation for the @Data constructor. It did
not include the transient fields.
|
|
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!)
|
|
pretty big fix in making the loop detection algorithm far more robust. Still not sure what was the problem, but the robustificationization helped.
|
|
should run in java 1.5, so that an eclipse started on a 1.5 JVM will still run lombok.
|
|
|
|
createHashCode method when there are 0 fields in the type (it would generate a local variable never used warning!)
|
|
throw eclipse errors if you had 0 non-static fields.
|
|
deepToString, and added @Override in case people have warnings for missing @Override annotations on.
|
|
|
|
without any raw generics warnings - it is effectively done.
|
|
directly to other nodes (e.g. from a FieldDeclaration's type to a method argument) is NOT a good idea, as this screws up when
the TypeReference object represents a generic type (like 'T') - each instance of a generic type has a different resolution, but 1 TypeReference object can only hold 1 resolution.
Thus, a copyType() method has been written, and the Handle* classes have been updated to use it.
Also, generateEquals() is half-finished in HandleData.
|
|
** DO NOT REUSE TYPEREFERENCE OBJECTS **
because that makes the binding process go pearshaped - after hte first run, that TypeReference object's binding parameter is set, and as its set, the resolver won't bother re-resolving it.
However, each parse run starts with new scope objects, and any 2 bindings created by different scopes aren't equal to each other. urrrrrrgh!
Fortunately, a lot of code that 'fixed' methods by adding bindings and scope have all been removed, as the parser patch point is well before these bindings are created. Thus:
** NEVER CREATE YOUR OWN BINDINGS AND SCOPE OBJECTS **
because if it comes down to that, you're doing it entirely wrong. That's eclipse's job. We're patching where we are so you don't have to do this.
|
|
static constructor not so much.
|
|
access level for @Getter and @Setter have now just been hardcoded in GetterHandler and SetterHandler.
Added ability to look up the Node object for any given AST object on Node itself, as you don't usually have the AST object.
Added toString() method generating to @Data, and this required some fancy footwork in finding if we've already generated methods, and editing a generated method to fill in binding and type resolutions. HandleGetter and HandleSetter have been updated to use these features.
Exceptions caused by lombok handlers show up in the eclipse error log, but now, if they are related to a CompilationUnit, also as a problem (error) on the CUD - those error log entries are easy to miss!
Our ASTs can now be appended to. When you generate a new AST node, you should add it to the AST, obviously. Getter/Setter have been updated to use this.
|
|
and setters only,
not yet a constructor, toString, hashCode, or equals.
HandleGetter and HandleSetter have been updated to handle static (theoretic; you can't put annotations on static fields normally).
You can now make AnnotationValue objects using just an annotationNode and a target type, as well as check if a given annotationNode is likely to represent a target annotation type. This is in Javac and Eclipse classes.
HandleGetter and HandleSetter can now be asked to make a getter/setter, and will grab access level off of a Getter/Setter annotation, if present.
|