Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-dev] new support for extra source locations

Sounds good.  Thanks for the clear explanation and doc comment George!  I committed the comment. 

 

I’m also going to add a note on supporting multiple source locations in problem list items to the UI doc I’m working on.  I figure that those additional locations should be linked by relations, but that info can be extracted from structure model.

 

Mik

 


From: aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of George Harley1
Sent: Wednesday, January 21, 2004 8:12 AM
To: aspectj-dev@xxxxxxxxxxx
Cc: aspectj-dev@xxxxxxxxxxx; aspectj-dev-admin@xxxxxxxxxxx
Subject: Re: [aspectj-dev] new support for extra source locations

 


Hi Mik,

This new call went in during the fixing of defect 41952. It enables message creators to make compound messages that contain a primary source location (obtained using getSourceLocation()) and a collection of optional secondary locations which make sense to include in the message. The criteria for setting the secondary locations is up who creates the message. Class org.aspectj.bridge.Message has a new constructor that takes an array of ISourceLocation instances.

Here would be my initial stab at adding Javadoc to the org.aspectj.bridge.IMessage interface ...

      /**
         * @return List of <code>ISourceLocation</code> instances that indicate
         * additional source locations relevent to this message as specified by the
         * message creator. The list should not include the primary source location
         * associated with the message which can be obtained from
         * <code>getSourceLocation()<code>.
         * <p>  
         * An example of using extra locations would be in a warning message that
         * flags all shadow locations that will go unmatched due to a pointcut definition
         * being based on a subtype of a defining type.
         * @see <a href="">AspectJ bug 41952</a>
         */
        public List getExtraSourceLocations();


We made some updates to org.aspectj.tools.ajc.Main and org.aspectj.bridge.MessageUtil so that these compound messages now get written out to the console/command line using the following format ...

< ...message including the primary source location...>
        see also: <extra source location info>
        see also: <extra source location info>
        :
        etc

(it's a tab before the "see also:")

For example, you would see something like the following on your command line if you did a compile of tests/bugs/DeclaringTypeWarning.java (the test case for the 41952 bug) using the latest out of CVS head ...


C:\DeclaringTypeWarning.java:12 declare warning : call(void B.run())
        see also: C:\DeclaringTypeWarning.java:19
C:\DeclaringTypeWarning.java:6 does not match because declaring type is A, if match desired use target(B) [Xlint:unmatchedSuperTypeInCall]
        see also: C:\DeclaringTypeWarning.java:14


Best regards,
George
________________________________________
George C. Harley


 

"Mik Kersten" <beatmik@xxxxxxxxx>
Sent by: aspectj-dev-admin@xxxxxxxxxxx

21/01/2004 06:53
Please respond to aspectj-dev

       
        To:        <aspectj-dev@xxxxxxxxxxx>
        cc:        
        Subject:        [aspectj-dev] new support for extra source locations

       



There's a new org.aspectj.bridge.IMessage.getExtraSourceLocations() method.
Could someone please add a Javadoc comment documenting what these are?

I can imagine many uses for messages with multiple sourcelines, like
pointing to both the declare and the offending location.  Previously when it
came time for us to expose this in the UI the link would come from the ASM,
since there should always be a structural relationship between the two
locations.  But perhaps we've decided to print multiple source locations
with messages on the command line?  (I've wanted javac to do that in a few
cases when it chooses to print only one end of an error involving an
inheritance relationship.)

Thanks,

Mik

--
http://kerstens.org/mik




_______________________________________________
aspectj-dev mailing list
aspectj-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/aspectj-dev


Back to the top