[
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]
Wes
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
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