[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [aspectj-dev] New build errors in sept 11 release of ajc
|
This bug is now fixed in CVS HEAD, and Macneil's test case has been
added to the test suite.
-Jim
Adrian Colyer wrote:
I had a hunch we needed Jim ;-) And the explanation makes perfect sense
- another nugget to file away...
-- Adrian
Adrian_Colyer@xxxxxxxxxx
*Jim Hugunin <lists@xxxxxxxxxxx>*
Sent by: aspectj-dev-admin@xxxxxxxxxxx
12/09/2003 16:23
Please respond to aspectj-dev
To: aspectj-dev@xxxxxxxxxxx
cc:
Subject: Re: [aspectj-dev] New build errors in sept 11
release of ajc
Macneil Shonle wrote:
>>I think this is the tightening of a compiler loophole rather than a newly
>>introduced bug - but since this program has been working since 1.0.6 I'd
>>like Jim to verify my assessment!
>> protected pointcut loadExecutions( Key key ):
>> ContainerLoader.containerLoads( *, ContainerDescriptor )
>>&& args(key);
>>
>>(please let me know if your system works as intended with this change).
Unfortunately, this is a new bug rather than a loophole tightening. The
problem was caused by moving name binding in pointcut declarations to
happen before declare parents are evaluated. Because of this, the
compiler doesn't know that ContainerDescriptor isa Key when resolving
the ContainerLoader.containerLoads reference.
The change in ordering was made to fix a bug reported in declare error
and declare soft whose pcds where being evaluated before name binding
had happened in the pointcut declarations. Unfortunately, declare error
and declare soft are concretized at the same time as declare parents
(and all other declares ;-), so this move also led to the regression
noted above.
FYI - AspectJ's static typing rules in pcd's work the opposite way that
a standard method call does. This is because information is flowing out
of the call rather than into it. The containerLoads pcd promises that
it will provide an instanceof the ContainerDescriptor class. Users of
this pcd can treat this object as if it was a ContainerDescriptor or any
SUPER type without any typesafety issues.
-Jim
