Hi again.
Actually I have been wondering about this... Both declarations are
identical, and they both have a good reason to exist in the first
place. The Refactoring package requires the declaration if compiled
without Java7Frontend - and vice versa. But when they are both
compiled together, both (equal) declarations clash.
I now wonder:
(1) Is there a good reason for reporting an error within JastAdd or
could one not instead just silently accept that there are two equal
declarations of the same attribute?
(2) If an error message is preferred, is there at least a way for a
third party like me, who happens to use both modules, to write an
adapter that somehow avoids the error message? (I guess "refine" won't
work here...)
Cheers,
Eric
On 6 February 2013 20:10, Eric Bodden <eric.bodden_at_ec-spride.de> wrote:
> Hi Jesper.
>
> Thanks a lot, that helped me find the culprit! It was caused by a
> change in the Refactoring project...
>
> [jastadd] /private/tmp/abc-build/JastAddJ/Java7Frontend/Literals.jrag:451
> Multiple declaration of attribute ASTNode.compilationUnit, previously
> declared in /private/tmp/abc-build/Refactoring/util/AST.jrag:36
>
> ------------------------------------------------------------------------
> r41 | xiemaisi_at_gmail.com | 2013-02-04 07:08:09 +0100 (Mon, 04 Feb 2013) | 1 line
> Fixed JastAddJ compatibility problem.
>
> I will contact Max Schäfer to ask him what this change is about. From
> what I can see it's rather causing a compatibility problem than fixing
> one.
>
> Cheers,
> Eric
>
>
> On 6 February 2013 17:49, Jesper Öqvist <jesper.oqvist_at_cs.lth.se> wrote:
>> Hi Eric,
>>
>> If you are using an official JastAdd release it is highly unlikely that this
>> is caused by a problem with the JastAdd2 version you are using, since the
>> last release was a couple months ago and you should have seen the same error
>> before now if nothing has really changed in your code.
>>
>> The error reporting by JastAdd2 can obviously be improved here, so I have
>> jury rigged a JastAdd2 jar that prints improved error messages for
>> specifically multiple declarations of inherited attributes. Try to compile
>> with this JastAdd2 version and hopefully we can shed some light on this
>> mystery!
>>
>> Dropbox link for JA2 test build:
>> https://www.dropbox.com/s/qemydrnaejaeeh9/jastadd2.jar
>>
>> /Jesper
>>
>>
>>
>> On 02/06/2013 04:53 PM, Eric Bodden wrote:
>>>
>>> Hi again.
>>>
>>> Ok, I can definitely confirm that the problem also occurs on my machine.
>>>
>>> It is really strange. The attribute JastAdd complains about is
>>> definitely defined just once in the file
>>> (/JastAddJ/Java7Frontend/Literals.jrag) and I also cannot find any
>>> other .jrag file that would show a conflicting declaration. Also, when
>>> I simply remove the declaration "inh CompilationUnit
>>> ASTNode.compilationUnit();" the error disappears, which seems to
>>> indicate that there is another declaration somewhere!?
>>>
>>> To me this really looks like an odd bug in JastAdd itself but I also
>>> don't understand why this is happening now but wasn't happening four
>>> days ago. As far as I can see, nothing changed.
>>>
>>> Eric
>>>
>>> On 6 February 2013 13:06, Eric Bodden <eric.bodden_at_ec-spride.de> wrote:
>>>>
>>>> Hmm, ok that's funny...
>>>>
>>>> I just found out that we already *are* using the stable version. This
>>>> seems to be our current configuration...
>>>>
>>>> abc
>>>> https://svn.sable.mcgill.ca/abc/trunk/aop/abc
>>>> abc-ja
>>>> https://svn.sable.mcgill.ca/abc/trunk/aop/abc-ja
>>>> abc-ja-exts
>>>> https://svn.sable.mcgill.ca/abc/trunk/aop/abc-ja-exts
>>>> abc-testing
>>>> https://svn.sable.mcgill.ca/abc/trunk/aop/abc-testing
>>>> JastAddJ
>>>>
>>>> http://svn.cs.lth.se/svn/jastadd-oxford/projects/branches/JastAddJ-stable/
>>>> JastAddExtensions/ControlFlowGraph
>>>>
>>>> http://svn.cs.lth.se/svn/jastadd-oxford/projects/trunk/JastAddExtensions/ControlFlowGraph
>>>> JastAddExtensions/IntertypeDeclarations
>>>>
>>>> http://svn.cs.lth.se/svn/jastadd-oxford/projects/trunk/JastAddExtensions/IntertypeDeclarations
>>>> JastAddExtensions/JimpleBackend
>>>>
>>>> http://svn.cs.lth.se/svn/jastadd-oxford/projects/trunk/JastAddExtensions/JimpleBackend
>>>> JastAddExtensions/Jimple1.5Backend
>>>>
>>>> http://svn.cs.lth.se/svn/jastadd-oxford/projects/trunk/JastAddExtensions/Jimple1.5Backend
>>>> JastAddExtensions/JavaFlattening
>>>>
>>>> http://svn.cs.lth.se/svn/jastadd-oxford/projects/trunk/JastAddExtensions/JavaFlattening
>>>> JastAddExtensions/SootJastAddJ
>>>>
>>>> http://svn.cs.lth.se/svn/jastadd-oxford/projects/trunk/JastAddExtensions/SootJastAddJ
>>>> Refactoring
>>>> https://jrrt.googlecode.com/svn/trunk
>>>>
>>>> I guess I will next try perform the very same build locally on my
>>>> machine to see what may be causing the problem.
>>>>
>>>> Eric
>>>>
>>>>
>>>>
>>>> On 6 February 2013 13:02, Eric Bodden <eric.bodden_at_ec-spride.de> wrote:
>>>>>
>>>>> Hello.
>>>>>
>>>>> Thanks Jesper/Görel for the suggestion. I will modify our build
>>>>> accordingly to see if that fixes the problem.
>>>>>
>>>>> Cheers,
>>>>> Eric
>>>>>
>>>>> On 6 February 2013 12:29, Görel Hedin <gorel_at_cs.lth.se> wrote:
>>>>>>
>>>>>> Hi Eric,
>>>>>> I think it would be a better idea if you use the latest stable branch:
>>>>>>
>>>>>> http://svn.cs.lth.se/svn/jastadd-oxford/projects/branches/JastAddJ-stable/
>>>>>> That way, you will be sure you are using something we have already run
>>>>>> all
>>>>>> our local tests on. And if we make changes that will require changes in
>>>>>> downstream projects, the goal is that they will be documented in the
>>>>>> ChangeLog file.
>>>>>> --Görel
>>>>>> 6 feb 2013 kl. 10:11 skrev Jesper Öqvist:
>>>>>>
>>>>>> That's up to you, but you should be aware that it is often unstable.
>>>>>>
>>>>>> /Jesper
>>>>>>
>>>>>> On 02/06/2013 09:07 AM, Eric Bodden wrote:
>>>>>>
>>>>>> Hello.
>>>>>>
>>>>>>
>>>>>> Do you use the JastAdd trunk repository?
>>>>>>
>>>>>> Yes I think so. Is that not a good idea?
>>>>>>
>>>>>>
>>>>>> Eric
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> JastAdd mailing list
>>>>>> JastAdd_at_cs.lth.se
>>>>>> https://mail1.cs.lth.se/cgi-bin/mailman/listinfo/jastadd
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> JastAdd mailing list
>>>>>> JastAdd_at_cs.lth.se
>>>>>> https://mail1.cs.lth.se/cgi-bin/mailman/listinfo/jastadd
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
>>>>> Head of Secure Software Engineering Group at EC SPRIDE
>>>>> Tel: +49 6151 16-75422 Fax: +49 6151 16-72051
>>>>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>>>>
>>>>
>>>>
>>>> --
>>>> Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
>>>> Head of Secure Software Engineering Group at EC SPRIDE
>>>> Tel: +49 6151 16-75422 Fax: +49 6151 16-72051
>>>> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
>>>
>>>
>>>
>>
>>
>> _______________________________________________
>> JastAdd mailing list
>> JastAdd_at_cs.lth.se
>> https://mail1.cs.lth.se/cgi-bin/mailman/listinfo/jastadd
>>
>
>
>
> --
> Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
> Head of Secure Software Engineering Group at EC SPRIDE
> Tel: +49 6151 16-75422 Fax: +49 6151 16-72051
> Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
--
Eric Bodden, Ph.D., http://sse.ec-spride.de/ http://bodden.de/
Head of Secure Software Engineering Group at EC SPRIDE
Tel: +49 6151 16-75422 Fax: +49 6151 16-72051
Room 3.2.14, Mornewegstr. 30, 64293 Darmstadt
Received on Thu Feb 07 2013 - 23:35:49 CET