RE: [aspectj-users] Tracing declare error messages back to the aspect

["Mik Kersten" <beatmik@xxxxxxx>]

It has been bugging me for a while that we don't have this support in the
IDEs.  The easiest way to make this work is to add the "affects / affected
by" relationship for declare error & warning.  When a declare-produced
compiler message takes you to the offending sourceline you will be able to
use either the outline view or the inline annotation to seek back to the
originating declaration.  That should be straightforward to add so unless
there are better suggestions I will add it to my list.  Note that unless we
special-case it this would also add the corresponding links below the
declare.  That's a bit redundant since they also show up in the task list,
but that just means that we have the same information in multiple views.

It would be nicer to do this navigation from within the task list.  However,
this is a more general problem since the same issue arises with Java errors.
When you create an error related to inheritance, say you made an overriding
method differ only by return type, the error message will only navigate you
to the subclass.  But you may have made the mistake in the superclass.  So
when a message is about a relationship between different source locations,
rather than a single source location, it would be nice to have a means of
navigating to multiple locations from that message.

Regarding the "Quick Fix" style heuristics for error messages: these would
be great to have as well, but we'll have to get through the more pressing
IDE features first.

Mik

--
http://kerstens.org/mik
 

> -----Original Message-----
> From: aspectj-users-admin@xxxxxxxxxxx [mailto:aspectj-users-
> admin@xxxxxxxxxxx] On Behalf Of Ron Bodkin
> Sent: Friday, July 11, 2003 6:18 PM
> To: aspectj-users@xxxxxxxxxxx
> 
> I think this is a great suggestion. I've often wanted to be able to
> navigate back to the source of a declare error/warning in the IDE.
> 
> As a more distant future, it would be nice to include "quick fix" options
> too: to ignore it, or patterns to change the code to comply. This would
> only apply in IDEs but might be suitable for AJDE rather than specific
> implementations. It is interesting that IntelliJ is building their own
> tightly integrated IDE support, rather than using AJDE.
> 
> Ron
> 
> Ron Bodkin
> Chief Technology Officer
> New Aspects of Security
> m: (415) 509-2895
> 
> > ------------Original Message-------------
> > From: Wes Isberg <wes@xxxxxxxxxxxxxx>
> > To: "aspectj-users@xxxxxxxxxxx" <aspectj-users@xxxxxxxxxxx>
> > Date: Thu, Jul-10-2003 1:50 PM
> > Subject: [aspectj-users] Tracing declare error messages back to the
> aspect
> >
> > Ron's email prompts me to ask another question on declare-error:
> >
> > The compiler emits error messages stating the rule and the offending
> > source code, but they do not trace automatically back to the declare
> > error/warning statement.  Sometimes instead of changing the source code
> > you want to change or omit the rule, and you have search the aspect
> > sources for the error message text.  This is informal at best and won't
> > work for library aspects.
> >
> > One solution would be to have a mode in the compiler that also printed
> > the signature of the enclosing aspect (the declare error/warning
> > statement itself does not have a signature).  A variant is to print the
> > source location for the declare, only defaulting to the signature if
> > source were not available.  We might even want to enable this as a
> > "lint" mode, though that's a stretch.
> >
> > Further, it would be great if IDE support could navigate back to the
> > declare error statement.  This might be hacked into our current
> > IMessage/ISourceLocation implementation using a downcast to an
> > ISourceLocation implementation that actually carried both source
> > locations, but defaulted to the error source.
> >
> > So:
> > - Do others think this is a problem?
> > - Are there other use-case scenarios for declare-error to consider?
> > - Any obviously-better implementation strategies?
> >
> > For this to become a feature, we'd need to start with some demand from
> > users and a feature request in the bug database.
> >
> > Wes
> >
> > _______________________________________________
> > aspectj-users mailing list
> > aspectj-users@xxxxxxxxxxx
> > http://dev.eclipse.org/mailman/listinfo/aspectj-users
> >
> _______________________________________________
> aspectj-users mailing list
> aspectj-users@xxxxxxxxxxx
> http://dev.eclipse.org/mailman/listinfo/aspectj-users