Age | Commit message (Collapse) | Author |
|
|
|
|
|
|
|
transplanted. It shouldn't matter (runPostCompiler will call lombok.jar code, so if there is a classloader issue, transplanting won't help), and roel thinks it might help debug an issue with Springsource gradle plugin for eclipse.
|
|
@Synchronized [Issue #588]
|
|
below; fixed.
|
|
some copyright headers.
|
|
JavacResolution. We've unified this (and fixed the fact that the JavacAST variant didn't work with javac8).
|
|
|
|
who knows what. At any rate, Roel is absolutely sure this will fix it, so, hey, who am I to argue? NB: Unicum
|
|
Conflicts:
src/core/lombok/core/Version.java
src/core/lombok/javac/handlers/HandleConstructor.java
test/transform/resource/messages-delombok/EqualsAndHashCodeWithSomeExistingMethods.java.messages
test/transform/resource/messages-ecj/EqualsAndHashCodeWithSomeExistingMethods.java.messages
|
|
values, so we now work around that javac bug).
|
|
- Prevent NPE in javac and give a proper warning in both eclipse and javac
- Add test cases
|
|
|
|
try and keep up with the complete rewrites of the doc comment parser from java6 to java7 to java8. Still doesn't actually work in jdk8, but only because of a last-mile issue. (we communicate the doc comment via compilationUnit.docComments but that changed types in jdk8, we just need to make a wrapper to make that work).
|
|
lombok.jar that works on all javas.
|
|
|
|
|
|
|
|
@Accessors to handle field accessors.
* various operations on names in javac were really slow; they are faster now.
|
|
|
|
|
|
annotation for onX instead of single underscore, which emits warnings on javac8+.
Also made dollars and Xes legal in addition to underscores, in case double underscore disappears later too.
|
|
|
|
|
|
|
|
this also solves the AssertionError in the Bits class on javac8-ea.
|
|
|
|
don't want it!"
|
|
|
|
it has major refactorings to make JDK6-8 support
possibly with much prettier code.
|
|
to program handlers that are not cross javac6-8 compatible?
|
|
still a looooong way to go.
|
|
Conflicts:
src/core/lombok/javac/handlers/JavacHandlerUtil.java
src/utils/lombok/javac/CommentCatcher.java
src/utils/lombok/javac/Javac.java
|
|
|
|
|
|
@Value's final-by-default and private-by-default with it; now
appropriate warnings are emitted)
* Builder now errors out on presence of most lombok annotations on an
explicit builder class.
* Builder now takes @FieldDefaults/@Value into account.
* Builder on type now generates the constructor as package private
instead of private to avoid synthetic accessor constructors.
* added a bunch of test cases.
* added a test case feature: If the expected file is omitted entirely
but there are expected messages, the differences in the output itself
are ignored.
* streamlined checking for boolean-ness (removed some duplicate code)
* added 'fluent' and 'chain' to @Builder.
|
|
coming up in autocomplete dialogs when guava's was intended.
|
|
has moved from experimental into core).
|
|
Eclipse breaks the javadoc out of the raw source and we can't modify that without breaking a billion things. To solve this issue we'd have to write some very complicated patches to intercept this process and somehow propagate the node that the javadoc is attached to AND translate from the ast model to dom or whatever is being used there. Not gonna happen for this low priority feature.
|
|
javadoc for getters/setters, and fixed pretty printer to no longer inject an extra newline at the top of javadoc.
|
|
as updates to all relevant documentation
|
|
javadoc from field to setter/getter in javac.
|
|
|
|
|
|
Implementing in javac, ecj still has to be done.
|
|
This caused a bunch of weirdness because eclipse changes a bunch of warnings and quickfixes based on this (such as complaining about lack of @SafeVarargs, a 1.7-only feature).
|
|
where _ANY_ mention of com.sun.tools.javac.tree.TreeMaker,
anywhere in a source file, would disable pretty much every
intelligent part of what makes the 'I' in IDE in eclipse:
No auto-complete, no 'go to declaration', etcetera, but only
since Eclipse Juno (not fixed in Kepler either). It's the
presence of src/stubs/com/sun/tools/javac/util/Context.java.
I've moved Context to a special stubs directory that's only used
for javac (so that we still get the benefit of getting some
warnings and such when making command line builds), and removed
the @Override annotations for where the stubbing is relevant
(for methods that exist in javac7 but not in javac6 on interfaces
we create implementations of). Furthermore, I did some extremely
tricky work in making our version actuall compatible with the
exact class signatures of both javac6- and javac7+'s versions;
generation of synthetic methods for reified type parameters was
causing havoc.
A big stack of 'here be voodoo' comments unfortunately added to
explain it all; necessary evil.
|
|
|
|
proper paths on Windows
|