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

Hi Adrian -

Your stuff looks much better, so it's worth doing as-is, esp.
the fix for wrong prefix of files/classes in jars.  I do prefer
your choice for emitting the jar path.

As for "see also" lines, if they aren't parsable by the normal
stdout clients (like emacs), then we should have an RFE for that.
Has anyone seen that?

Since you're looking at this now, a step back might help,
for now or later...

It seems like IMessage is not perfect for handling some kinds
of messages we have:

- error line and defining declare error or warning
- one of many conflicting member declarations
- (Do any xlint warnings have different structures?)
- info from weaver?

We're augmenting it by kind (WEAVER_INFO?) and appendage
(details, extra source location...), so it is starting to smell.
(Details appears vestigial.  Extra source location has no context
for why it is being appended.)

One way to work around this now is instead to have different
IMessage implementations (e.g., DeclaredMessage, XLintMessage,
ConflictMessage, subclassing Message or EclipseMessage(?)).
Further, we might want an ISourceLocation implementation
"BinaryLocation" for sources in jar files.  (It might even
take on responsibility for pulling associated text from
a source path or src.zip.)

Doing this means that clients of IMessage and ISourceLocation
continue to work, but clients that know about BinaryLocation
and DeclareMessage, etc. can tailor accordingly.  This change
is nice b/c we don't change anything about how we handle messages
per se, and changing to subtypes should make sense in the context
they are being generated.  We can even have a "normal" message
subtype and audit away direct (non-testing) uses of Message.

Two unanswered and deferred questions:

(1) Whether we can continue to generate each message incrementally
but easily gather all associated messsages (deow, conflicts).
to facilitate message-handling strategies that group related
messages.  [defer until needed by client/strategy]

(2) Whether we should delegate to the smarter types for their
command-line renderings or keep using a renderer. [defer until
need renderer-less rendering]


Adrian Colyer wrote:

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

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?


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