| Age | Commit message (Collapse) | Author |
|---|
|
the generated annotations seems to fix the David Lynch bug (issue #41).
Saving this now before further fiddling breaks things again.
|
|
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.
|
|
|
|
|
|
@NonNull/@Nullable and getter/setter/constructor generation) to 0, as eclipse mysteriously fails for annotations copied WITH source positions, but only on methods (which happens for @Getter).
|
|
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
|
|
|
|
|
|
legal reasons for using it, so, changed it: explicitly setting 'callSuper=false' removes the warning. You only get the warning
if callSuper is false because that's the default.
Fixes issue #13
|
|
annotation
The constructor will test for null-values
The constructor and static constructor will copy the NonNull annotations from the fields
|
|
|
|
the parameter
@Getter will copy them to the getter method
Added @NonNull to lombok to support null-checks in the setter
|
|
|
|
'plus' nodes (e.g. concatenating the infix ", " and a field name literal such as "width=" into ", width=".
Also removed the [] brackets from the supercall, as, if you're chaining to another lombok-generated toString, those are superfluous - lombok's toString includes parentheses already.
|
|
new annotation, @EqualsAndHashCode.
Addresses issue #8
|
|
|
|
has now moved from HandleData to the new HandleToString.
|
|
entry now no longer causes ArrayIndexOutOfBoundsException, the setWarning method on a single item in an array initializer on eclipse
now generates the warning on just that node (like with errors), and the API of AnnotationValues has been updated to support setting errors/warning on any node.
|
|
|
|
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.
|
|
|
|
If boolean fields already start with a typical getter prefix (is, has, or get), lombok's @Getter will no longer generate its own prefix as well, so a field named 'hasFoo' will result in a getter named 'hasFoo()', not 'isHasFoo()'.
Also, if any likely getter name already exists for a boolean, a getter will not be generated. Thus, if your field is called 'hasFoo', and you already have a method named 'isFoo', then @Getter will not generate anything (and warn, unless the getter is being generated due to @Data).
This last mechanism works by taking the field name *AND* any other likely base names (defined by the field name being named as prefix+baseName, with prefix being is/has/get), and then prefixing all the likely fieldnames with is/has/get, and checking if any method with that name exists.
Of course, this means weird things are going to happen if you have 2 fields named 'isFoo' and 'hasFoo', but then, you'd be a real idiot if you did that.
|
|
|
|
|
|
the class would generate errors regarding IllegalArgumentException in setSourcePosition in ASTNode.
|
|
generating it" warnings
when the getter/setter already there was in fact generated by lombok, and fixed a bug
in eclipse where a boolean array's getter method would be called isFoo() instead of getFoo().
|
|
Also fixed a bug in javac's toString() generation for the @Data constructor. It did
not include the transient fields.
|
|
upon anymore when reporting errors.
They were logging 4 or more identical warnings per problem before this change.
|
|
|
|
package, of course),
and fixed a showstopper bug in the installer that would add -javaagent:lombok.jar to
eclipse.ini, which is wrong of course; it needs to be lombok.eclipse.agent.jar.
|
|
|
|
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!)
|
|
that would show up rarely or not at all.
|
|
|
|
|
|
Spruced up @Cleanup's position settings and also forced initialization, because the error appears in a screwed up place if you don't, and we can't seem to move it.
|
|
|
|
anything else generates a warning.
|
|
the same thing for javac.
|
|
pretty big fix in making the loop detection algorithm far more robust. Still not sure what was the problem, but the robustificationization helped.
|
|
caused nested @Cleanup annotations to simply be ignored (rebuild was broken).
HandleCleanup seems to work swimmingly now on both targets. yay!
|
|
(exceptions from the cleanup call WILL mask exceptions from the body - this isn't intended, but it's just not possible to fix this without java 7 features or requiring a rewrite of the class file data.
Tried tactics, and why they won't work:
- Replace every 'return', 'break', and 'continue' statement (for the latter 2, only if they break/continue out of the try block) with a block that first sets a uniquely named flag before doing the operation.
Then, check that flag in the finally block to see if the cleanup call should be guarded by a try/catchThrowable. This doesn't work, because its not possible to instrument the 4th way out of a try block without throwing an exception: Just letting it run its course. Tossing a "#flag = true;" at the end may cause a compile time error if the code is not reachable, but figuring that out requires resolution and quite a bit of analysis.
- Put catch blocks in for all relevant exceptions (RuntimeException, Error, all exceptions declared as thrown by the method, and all types of exceptions of the catch blocks of encapsulating try blocks.
This doesn't work, partly because it'll fail for sneakily thrown exceptions, but mostly because you can't just catch an exception listed in the 'throws' clause of the method body; catching an exception
that no statement in the try block can throw is a compile time error, but it is perfectly allright to declare these as 'thrown'.
- Put in a blanket catch Throwable to set the flag. Two problems with this:
First, sneaky throw can't be done. Thread.stop invokes a security manager and triggers a warning, Calling a sneakyThrow method creates a runtime dependency on lombok, constructing a sneakyThrow in-class creates visible methods or at least visible class files, and creating a new class via Class.loadClass would be very slow without caching - which gets you the same issues.
Secondly, this would mean that any statements in the try body that throw an exception aren't flagged to the user as needing to be handled.
The Cleanup annotation now also calls the cleanup method for you, and will call it at the END of the current scope. The following plans have been tried and abandoned:
- Cleanup right after the final mention. This doesn't work, because the final mention may not be the final use-place. Example:
@Cleanup InputStream in = new FileInputStream(someFile);
InputStreamReader reader = new InputStreamReader(in);
reader.read(); //oops - in is already closed by now.
- Require an explicit var.cleanup() call and consider that the cue to close off the try block.
This doesn't work either, because now variables set in between the @Cleanup declaration and the var.cleanup() call become invisible to following statements. Example:
@Cleanup InputStream in = new FileInputStream(someFile);
int i = in.read();
in.close();
System.out.println(i); //fail - i is inside the generated try block but this isn't, so 'i' is not visible from here.
By running to the end of visible scope, all these problems are avoided. This does remove the flexibility of declaring where you want a close call to be executed, but there are two mitigating factors available:
1) Create an explicit scope block. You can just stick { code } in any place where you can legally write a statement, in java. This is relatively unknown, so I expect most users will go for:
2) Just call close explicitly. I've yet to see a cleanup method which isn't idempotent anyway (calling it multiple times is no different than calling it once).
During the course of investigating these options, the AST code has been extended to support live replacement of any child node, including updating the actual underlying system AST as well as our own.
Unfortunately, this code has NOT been tested. It was rather a lot of work so I'm leaving it in, and at least for eclipse it even seemed to work.
|
|
should run in java 1.5, so that an eclipse started on a 1.5 JVM will still run lombok.
|
|
|
|
is not neccessarily the proper target anyway. Rolled our own DefaultProblem subclass for problem reporting.
|
|
Eclipse will now also hold off on running @PrintAST handlers until the very end. Simple generators such as @Getter didn't need this, because PrintAST's handler will hold off until eclipse does a full parse,
but when changing the innards of methods, you would likely not see what you did. Fixed that.
Also, PrintAST has an option to, instead of diving into the ASTNodes of bodies (methods, initializers, etc), to just render the java code, to see if the AST creation/rewriting you've been doing looks like the java code you intended.
|
|
were set to the value of the last annotation method. e.g in:
@Foo(bar=10), ALL methods in the Foo annotation were presumed to be listed, and set to 10. This was obviously causing problems. Fixed it.
|
|
|
|
There's one serious problem though: The cleanup routine modifies the eclipse internal AST, but doesn't update our bi-directional AST. Thus, or example, having a @Cleanup annotation inside the scope
of another @Cleanup fails, because the application of the second one climbs up to the wrong block level (the original block level instead of newly built try block).
|
|
|
