[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [aspectj-dev] compiler messages


I was chiefly asking about the deltas between HEAD and the stuff I've been working on this last week or so (i.e. adding context and a see also for binary source locations).  ("See also" messages have been in HEAD for a couple of months now from memory).

We *could* also change the way 'see also' messages are printed in general, and indeed give special treatment to declared errors and warnings (I agree that we need to use a differentiated icon in AJDT), but I'm not currently planning to include that in the changes I'm making. The "see also" mechanism supports cross-cutting error messages in general, and is not tied to just the case of a matched deow, so we'd need some more contextual information in a message before we could change the formatting. If we do want to change this for the release, we'll need to reach consensus on this list on what we should do, and an implementor will have to step forward too...

-- Adrian
Adrian_Colyer@xxxxxxxxxx



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

09/03/2004 16:33
Please respond to aspectj-dev

       
        To:        <aspectj-dev@xxxxxxxxxxx>
        cc:        
        Subject:        RE: [aspectj-dev] compiler messages



I do like it.  Since sourcelines are typically very long, consider shortening that part to remove the tab, and perhaps even shorten to just “see: ”.  Javadoc already makes people consider “see” as an additional reference.  This is pretty similar to how javac prints additional info, without indentation, e.g.:
 
Hello.java:18: cannot resolve symbol
symbol  : variable length
location: class java.lang.String
    if (msg.length != 0)
           ^
In part because of the length issue, I also wonder if it could make sense to print the qualified name rather than the sourceline.  Perhaps that’s because I’m finding the pointers into the JARs great, and not quite enough since I want to know where to go in the JAR.  Also, as another alternative could consider replacing “also see” and make the fact that it came from a declare *explicit*, if that’s the case.  It will help to see that this is a slightly different kind of error than all the other ones—important if you need to fix your compile errors before expecting the declare error to be accurate (so I also think that AJDT should use slightly different icons for declared errors and warnings).
 
C:\ColyerRoot\...\org.aspectj.ajdt.core\D.java:6 should only call bad from C
declare warning: com.foo.bar.ErrorHandlingPolicy

 
C:\ColyerRoot\...\org.aspectj.ajdt.core\D.java:6 can only call bad from C
declare error: com.foo.bar.policies.ErrorHandlingPolicy (in policies.jar)

 
There are few tradeoffs here, but something along these lines could avoid the path length problem, and make differentiating and locating the declaring statement easier.  
 
Mik
 



From: aspectj-dev-admin@xxxxxxxxxxx [mailto:aspectj-dev-admin@xxxxxxxxxxx] On Behalf Of Adrian Colyer
Sent:
Tuesday, March 09, 2004 6:07 AM
To:
aspectj-dev@xxxxxxxxxxx
Subject:
Re: [aspectj-dev] compiler messages

 

Hi Wes,

I'm in favour of your proposal.


Since we're on topic, I also want to gather opinions about error message display in the compile loop restructure I've been doing. One of the consequences of that work is that AjCompiler now tries very hard to match a message coming from the weaver to the inputs (source and binary source) of the compile. This enables me to put out more context with messages originating from the weaver. Here are some samples of the messages coming out (none of this is commited in the tree yet). Do folks like this? Want to tweak the output in any way?


For compiling tests/errors/DeclareError.java:

AspectJ 1.1.1 would output:

C:\ColyerRoot\...\tests\errors\DeclareError.java:5 can only call bad from C


AspectJ HEAD outputs:

C:\ColyerRoot\...\tests\errors\DeclareError.java:5 can only call bad from C

       see also: C:\ColyerRoot\...\tests\errors\DeclareError.java:25


(better, since we also tell the user where the declare statement can be found in the "see also")


My private branch outputs:

C:\ColyerRoot\...\tests\errors\DeclareError.java:5 can only call bad from C

new C().bad();

^^^^^^^^^^^^^^

       see also: C:\ColyerRoot\...\tests\errors\DeclareError.java:25


(adds in source context information whenever it can).


Here's how it looks when there is no source code available (i.e. we are passing binary source into the compiler). I took the contents of tests/errors/DeclareError.java and split each type into its own file, then compiled all but the aspect into cdd.jar. The resulting output is now the result of compiling A.java (the aspect) with -injars cdd.jar.


AspectJ 1.1.1 would output:

C:\ColyerRoot\...\org.aspectj.ajdt.core\D.java:6 can only call bad from C


note that the file is reported as <working directory>\D.java. The D.java portion is the file name contained within D.class in cdd.jar. The prefix is appended by our message printer, even though in this case it is wrong (D.java was never in that directory).


AspectJ HEAD outputs:

C:\ColyerRoot\...\org.aspectj.ajdt.core\D.java:6 can only call bad from C

       see also: C:\ColyerRoot\...\tests\errors\amctemp\DeclareError.java:25


(adds the location of the declare statement, as before).


My private build outputs:


D.java:6 can only call bad from C

(no source information available)

       see also: C:\ColyerRoot\Data\AspectJDev\AspectJ_M6_Port\tests\errors\amctemp\A.java:5

       see also: C:\ColyerRoot\Data\AspectJDev\AspectJ_M6_Port\tests\errors\amctemp\cdd.jar


This informs the user that the error was found in binary source (no source information available), and adds a see also: line for the location of the binary source (in this case cdd.jar). The prefix is added to D.java only if file.exists().

Note that an alternate design would be to not include the "see also" for the jar, but instead output something like this:


C:\ColyerRoot\Data\AspectJDev\AspectJ_M6_Port\tests\errors\amctemp\cdd.jar (D.java:6) can only call bad from C

(no source information available)

       see also: C:\ColyerRoot\Data\AspectJDev\AspectJ_M6_Port\tests\errors\amctemp\A.java:5


I didn't do this because (a) for classes in packages the first line will probably get too long, and (b) it means that the filename in the source location is not a valid filename, and clients of the API might reasonably expect it to be so.


-- Adrian
Adrian_Colyer@xxxxxxxxxx

  Wes Isberg <wes@xxxxxxxxxxxxxx>
Sent by: aspectj-dev-admin@xxxxxxxxxxx

08/03/2004 22:46
Please respond to aspectj-dev

       
       To:        "aspectj-dev@xxxxxxxxxxx" <aspectj-dev@xxxxxxxxxxx>

       cc:        

       Subject:        [aspectj-dev] compiler messages




For compiler messages, I've noticed there's no way to distinguish errors
from warnings.  Javac prefixes warnings with "warning: ".  Anyone object
to our doing that when they are output to the command line?

Wes


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