Re: [project lombok] eclipse problem (IllegalArgumentException)

733 views
Skip to first unread message

Reinier Zwitserloot

unread,
Oct 1, 2012, 4:43:41 PM10/1/12
to project...@googlegroups.com
Well, that's bad! This isn't happening with lombok in the trace (but it is certainly possible lombok left an AST in a state that will lead to this problem and it just ends up getting triggered by a different thread).

Something we could do is make a 'debugging' build of lombok which hooks into ASTNode.setSourceRange, catches this issue, and dumps into a log someplace as much information as it can find on the issue, most importantly the node affected. Then you know the file and the location and from there it should be much easier to diagnose which (if any) lombok handler is mucking things up.

Does that work for you?

Here's the debug build:


install as normal; it's a modified cutting edge build so you might wanna revert to your usual lombok.jar after this (just save that lombok.jar someplace, then run it as an executable when you have the debug info).

It replaces the thrown IllegalArgumentExceptions with ones that have a message with lots of data in it.


 --Reinier Zwitserloot



On Thu, Sep 27, 2012 at 6:55 PM, Peter van Rensburg <peter.van...@gmail.com> wrote:
hi

we have recently converted a large project to lombok and since running into some problems with eclipse unable to build the project. the following appears in the .log (eclipse indigo SR2):

java.lang.IllegalArgumentException
        at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java:2648)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2037)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:825)
        at org.eclipse.jdt.core.dom.ASTConverter.setModifiers(ASTConverter.java:4432)
        at org.eclipse.jdt.core.dom.ASTConverter.setModifiers(ASTConverter.java:4521)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:427)
        at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:183)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2659)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1220)
        at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:876)
        at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:577)
        at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:894)
        at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:859)
        at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356)
        at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111)
        at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:283)
        at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:225)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
        at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:150)
        at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193)
        at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:627)
        at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:338)
        at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60)
        at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254)
        at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:178)
        at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
        at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
        at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
        at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
        at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
        at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:513)
        at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:432)
        at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:305)
        at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

unfortunately i do not know exactly which code is the cause. i have seen a very similar stack trace caused by earlier lombok versions but those problems have been fixed since according to the google issues. 

this happens both in eclipse indigo and eclipse juno. 

lombok is working very well for us in other projects!

thanks
peter

--
You received this message because you are subscribed to the Google
Groups group for http://projectlombok.org/
 
To post to this group, send email to project...@googlegroups.com
To unsubscribe from this group, send email to
project-lombo...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/project-lombok?hl=en

Reinier Zwitserloot

unread,
Oct 21, 2012, 7:33:36 PM10/21/12
to project...@googlegroups.com
Good find!

Accepted that issue, bumped priority of it, mentioned this thread in it. We'll pick that up for the next release.

On Monday, October 15, 2012 6:18:48 PM UTC+2, Peter van Rensburg wrote:
looks like there's already a defect filed for it:

Reinier Zwitserloot

unread,
Oct 29, 2012, 8:10:03 PM10/29/12
to project...@googlegroups.com
Fixed; this fix is in the just released official latest version (0.11.6).

JDP

unread,
Sep 24, 2013, 12:46:29 AM9/24/13
to project...@googlegroups.com
Im getting this error with the 0.12 release and the edge release:

java.lang.IllegalArgumentException: startPos = -1 and length is 1241.
This breaks the rule that length must be 0 if startPosition is negative. Affected Node:
{
}

at lombok.eclipse.agent.PatchDiagnostics.setSourceRangeCheck(PatchDiagnostics.java:38)
at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2305)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1544)
at org.eclipse.jdt.core.dom.ASTConverter.convertToVariableDeclarationFragment(ASTConverter.java:3023)
at org.eclipse.jdt.core.dom.ASTConverter.convertToVariableDeclarationStatement(ASTConverter.java:3051)
at org.eclipse.jdt.core.dom.ASTConverter.checkAndAddMultipleLocalDeclaration(ASTConverter.java:403)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1105)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2404)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1790)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2428)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1107)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2524)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2440)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1107)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2404)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1790)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2428)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:537)
at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:186)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2679)
at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1222)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:885)
at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:581)
at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:894)
at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:859)
at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356)
at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111)
at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:283)
at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:225)
at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2345)
at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:150)
at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:629)
at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:340)
at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254)
at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:178)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:726)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:143)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:241)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)



eclipse.buildId=4.3.0.I20130605-2000
java.version=1.7.0_25
java.vendor=Oracle Corporation
BootLoader constants: OS=macosx, ARCH=x86_64, WS=cocoa, NL=en_US
Framework arguments:  -product org.eclipse.epp.package.jee.product -keyring /Users/jdp/.eclipse_keyring -showlocation
Command-line arguments:  -os macosx -ws cocoa -arch x86_64 -product org.eclipse.epp.package.jee.product -keyring /Users/jdp/.eclipse_keyring -showlocation


Reinier Zwitserloot

unread,
Sep 24, 2013, 6:56:04 AM9/24/13
to project...@googlegroups.com
Do you know which source file is causing this, and what are you doing when this happens? Lombok isn't itself in the stacktrace so we can't debug it with just this.


On Thursday, September 27, 2012 6:55:17 PM UTC+2, Peter van Rensburg wrote:
hi

we have recently converted a large project to lombok and since running into some problems with eclipse unable to build the project. the following appears in the .log (eclipse indigo SR2):

java.lang.IllegalArgumentException
        at org.eclipse.jdt.core.dom.ASTNode.setSourceRange(ASTNode.java:2648)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2037)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:825)
        at org.eclipse.jdt.core.dom.ASTConverter.setModifiers(ASTConverter.java:4432)
        at org.eclipse.jdt.core.dom.ASTConverter.setModifiers(ASTConverter.java:4521)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:427)
        at org.eclipse.jdt.core.dom.ASTConverter.buildBodyDeclarations(ASTConverter.java:183)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:2659)
        at org.eclipse.jdt.core.dom.ASTConverter.convert(ASTConverter.java:1220)
        at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:876)
        at org.eclipse.jdt.core.dom.CompilationUnitResolver.resolve(CompilationUnitResolver.java:577)
        at org.eclipse.jdt.core.dom.ASTParser.createASTs(ASTParser.java:894)
        at org.eclipse.jdt.apt.core.internal.env.BaseProcessorEnv.createASTs(BaseProcessorEnv.java:859)
        at org.eclipse.jdt.apt.core.internal.env.BuildEnv.createASTs(BuildEnv.java:356)
        at org.eclipse.jdt.apt.core.internal.env.AbstractCompilationEnv.newBuildEnv(AbstractCompilationEnv.java:111)
        at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.build(APTDispatchRunnable.java:283)
        at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.run(APTDispatchRunnable.java:225)
        at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:2344)
        at org.eclipse.jdt.apt.core.internal.APTDispatchRunnable.runAPTDuringBuild(APTDispatchRunnable.java:150)
        at org.eclipse.jdt.apt.core.internal.AptCompilationParticipant.processAnnotations(AptCompilationParticipant.java:193)
        at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.processAnnotations(AbstractImageBuilder.java:627)
        at org.eclipse.jdt.internal.core.builder.AbstractImageBuilder.compile(AbstractImageBuilder.java:338)
        at org.eclipse.jdt.internal.core.builder.BatchImageBuilder.build(BatchImageBuilder.java:60)
        at org.eclipse.jdt.internal.core.builder.JavaBuilder.buildAll(JavaBuilder.java:254)
        at org.eclipse.jdt.internal.core.builder.JavaBuilder.build(JavaBuilder.java:178)
        at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:728)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:199)
        at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:239)
        at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:292)
        at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
        at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:295)
        at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:351)
        at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:374)
        at org.eclipse.core.internal.resources.Workspace.buildInternal(Workspace.java:513)
        at org.eclipse.core.internal.resources.Workspace.build(Workspace.java:432)
        at org.eclipse.ui.actions.BuildAction$1.runInWorkspace(BuildAction.java:305)
        at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
        at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)

John Patterson

unread,
Sep 24, 2013, 7:33:15 PM9/24/13
to project...@googlegroups.com
The stacktrace I posted above does have Lombok in the top line:

at lombok.eclipse.agent.PatchDiagnostics.setSourceRangeCheck(PatchDiagnostics.java:38)

I'm not sure which file causes this because it happens when I save any file.

Reinier Zwitserloot

unread,
Sep 25, 2013, 9:56:57 AM9/25/13
to project-lombok
The exception was going to happen anyway; lombok patches in a call to our setSourceRangeCheck, because it adds useful information. Well, useful if we have the file that is causing it, which we don't.

Okay, I go to my eclipse, hit 'save', and I don't get this bug. In other words, I cannot reproduce it. If you don't give more information, we can't fix it. Here are some things to check:

* Does this happen on ANY file, or only some files? If it's only a couple of files, what lombok feature(s) if any are you using in those files?

* Do you have save actions turned on? If so, which save actions?


 --Reinier Zwitserloot


--
You received this message because you are subscribed to the Google Groups "Project Lombok" group.
To unsubscribe from this group and stop receiving emails from it, send an email to project-lombo...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

John Patterson

unread,
Sep 26, 2013, 9:58:29 PM9/26/13
to project...@googlegroups.com
I do not have save actions enabled.  I use GWT in the same project.  This error occurs when any Java file in the project is saved.  

Perhaps the error message could be modififed to show which file is causing the problem?


--
You received this message because you are subscribed to a topic in the Google Groups "Project Lombok" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/project-lombok/-iAnwlEzyd0/unsubscribe.
To unsubscribe from this group and all its topics, send an email to project-lombo...@googlegroups.com.

Reinier Zwitserloot

unread,
Oct 4, 2013, 8:16:38 AM10/4/13
to project...@googlegroups.com
No, we cannot easily add the filename to the exception. If it happens on _ANY_ file, even the simplest Hello World imaginable, I'm not sure what good that would do. We'd have to reproduce the environment to try and fix it, which would involve a bug report with: Download the (URL here to binaries) version of eclipse, then Download this (URL to binaries) eclipse plugin and add it to the eclipse downloaded earlier, then install lombok (version THIS) into this eclipse, then create any file and save it.

Jens Rieks

unread,
Jan 27, 2014, 2:25:23 PM1/27/14
to project...@googlegroups.com
Hi all,

I had the same problem and was able to reduce it to a simple example that causes the bug.

import java.util.List;
import lombok.Getter;
public class Example {
private static class Entry {}
@Getter
private final List<Example.Entry> list;
}

It seems to be caused by the @Getter for "<Example.Entry>". Removing the @Getter fixes the problem as well as using "List<Entry>" instead of "List<Example.Entry>".

(using STS 3.4.0.RELEASE build id 201310051614 with Lombok v0.11.8)

-Jens

Martin Grajcar

unread,
Jan 27, 2014, 6:02:10 PM1/27/14
to project...@googlegroups.com
Confirmed with Indigo Service Release 2, Build id: 20120216-185 (pretty old). The error seems to happen always, no Save Action needed, not even any saving needed. Happens both with the current HEAD (5782b90) and cdb4920.


--

Reinier Zwitserloot

unread,
Jan 31, 2014, 11:02:43 AM1/31/14
to project...@googlegroups.com
Cannot reproduce with plain old eclipse, kepler 20130614-0229.

So, what's going on?

(A) There's something special about Maaartin's / Jens's eclipses, such as a plugin I don't have.

(B) This occurs due to something that is no longer in more recent versions of the eclipse code base, thus indigo suffers from this and kepler doesn't, and as far as STS is concernend, I have no idea which version of eclipse they're basing themselves on.

(C) This occurs on STS but not Eclipse.

Any insights? We can't fix this without reproducing it first.

Jens Rieks

unread,
Jan 31, 2014, 12:14:03 PM1/31/14
to project...@googlegroups.com
I was able to reproduce it with "eclipse-standard-kepler-SR1-linux-gtk-x86_64.tar.gz": Version: Kepler Service Release 1, Build id: 20130919-0819
I can confim that the error does not occur with the default project setting. It looks like it is caused by "Organize Imports". Running it manually results in "Unexpected error in organize imports. See log for details.AST must not be null". Enabling "organize imports" as save action results in the error message mentioned in my previous mail.

Thank you,
Jens

Roel Spilker

unread,
Jan 31, 2014, 12:29:41 PM1/31/14
to project...@googlegroups.com

Could this be a duplicate of issue 631?

Martin Grajcar

unread,
Jan 31, 2014, 3:37:38 PM1/31/14
to project...@googlegroups.com
On Fri, Jan 31, 2014 at 5:02 PM, Reinier Zwitserloot <rein...@gmail.com> wrote:
Cannot reproduce with plain old eclipse, kepler 20130614-0229.

So, what's going on?

(A) There's something special about Maaartin's / Jens's eclipses, such as a plugin I don't have.

I installed a couple of things which I can't recall anymore. However, now I uninstalled or manually removed everything I could thing about and the problem remains.
 
(B) This occurs due to something that is no longer in more recent versions of the eclipse code base, thus indigo suffers from this and kepler doesn't,

I know I'm running an ancient eclipse, but I can't see a reason for switching.
 
and as far as STS is concernend, I have no idea which version of eclipse they're basing themselves on.

(C) This occurs on STS but not Eclipse.

Any insights? We can't fix this without reproducing it first.

I've found out that it has nothing to do with my metadata, so "only" my installation directory remains. I tried to debug it, but not everything works and I can't set a breakpoint in the relevant parts in org.eclipse.jdt.core.** - what exactly is needed to get it all working?

It looks like the Node List<Example.Entry> gets assigned the sourceEnd of  @Getter (confirmed by placing some dozens of slashes there). This seems to happen in retrieveClosingAngleBracketPosition where I can't debug. I guess already its arguments are wrong.

Could you advice me concerning the debugging?

Or I could give you my Eclipse... it's a quarter gigabyte, so it's doable.

Martin Grajcar

unread,
Jan 31, 2014, 9:15:11 PM1/31/14
to project...@googlegroups.com
No idea if it helps, here are some findings of mine: TL;DR all qualified names receive the position of the lombok annotation. Combined with a non-qualified name in parameterized type it leads to start > end

The shortest example for this bug is

@lombok.Setter
class X {
A<B.C> a; 

There are no imports needed, the bug happens anyway. There must be a non-qualified parameterized type with a qualified parameter (sorry for probably confusing all the terms). Things like A.B<C.D> don't produce this bug. It happens with @Getter, @Setter, or @Wither, but not with @EqualsAndHashCode. The following table gives the start and end positions for astNode in setSourceRangeCheck:

28  29 A SimpleName
28  29 A SimpleType
 0  14 B SimpleName <--- first wrong
 0  14 C SimpleName
 0  14 B.C QualifiedName
 0  14 B.C SimpleType
28  15 A<B.C> ParameterizedType

This claims that "B".length() is 14 and that it appears at position 0. At position 0 there's is the Setter annotation and the end fits too. All the components of the qualified name point to the annotation and so does the whole SimpleType. The ParameterizedType has a correct start (28), but its end was determined by a search starting at the end of its last (and only) parameter. It looks for a chevron and finds none, but this doesn't matter anymore. The end position is 15 and the length is negative.

Something like A<B.C, D> raises no exception, as D being a simple name retains its correct position and only the last parameter's position counts. Something like A.B.C works too, as it's misplaced, but there's no enclosing type expression, so nobody cares. Also something like A.B<C.D> works, as
ParameterizedQualifiedTypeReference as A.B get misplaced as well and determines the start, so start <= end holds.

Interesting is the case of java.util.List<java.lang.String>. There's no error, but nearly everything gets misplaced. In particular, there are two ParameterizedType there, both placed at the position of the annotation (as if copyType did nothing, but it copied everything).


Martin Grajcar

unread,
Jan 31, 2014, 9:52:28 PM1/31/14
to project...@googlegroups.com
That's it. The solution is not even worth a patch. In copyType you pass the original iRef.sourcePositions to the constructor and it gets shared between the original and the copy. That's why in the end everything has the same position.

This gets done several times and might be the cause of other bugs too. Maybe there's something else forgotten as well. I guess it's worth to check, probably via reflection, I'll try to do it.

Martin Grajcar

unread,
Feb 1, 2014, 12:37:34 PM2/1/14
to project...@googlegroups.com
I'm attaching the check, it reports things like

When copying Example.Entry[], copyType left the shared reference [J@24f89076 at path /sourcePositions/

when assertions are enabled. In this case it's the same bug as above, just in ArrayQualifiedTypeReference and it leads to wrongly determined position for type in a field  declaration. As this position doesn't get used for anything, it's harmless.

No idea if the check is worth including when the bug is fixed, but maybe there are more. I'm also attaching a trivial patch fixing the bug.

copyType-check.txt
0001-Stop-copyType-from-sharing-the-sourcePositions.patch

Martin Grajcar

unread,
Feb 1, 2014, 1:11:44 PM2/1/14
to project...@googlegroups.com
Apologies for spamming... my previous patch contains some random garbage. This one is right.

0001-Stop-copyType-from-sharing-the-sourcePositions.patch

Roel Spilker

unread,
Feb 4, 2014, 7:18:36 PM2/4/14
to project...@googlegroups.com
Hi Martin,

Thanks for the supplied code. We've reproduced the problem and applied your suggested modifications, and those fixed the problem. The last week, two issues were logged on our issue tracker, so this was a great moment to fix it.

Roel



On Sat, Feb 1, 2014 at 7:11 PM, Martin Grajcar <maaar...@gmail.com> wrote:
Apologies for spamming... my previous patch contains some random garbage. This one is right.

Reply all
Reply to author
Forward
0 new messages