| Bug in OCLAbstractAnalyzer [message #56033] |
Fri, 16 May 2008 11:18  |
 Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian,
I have detected a problem when resolving a featureCallExp which will
involve an implicit collect iterator.
Think about getting a collection of names from a collection of Classes.
for example the following expression should be useful
aCollectionOfClasses.name
because its implicit translated to
aCollectionOfClasses->collect(i | i.name);
If the name of a property doesn't exist, an NPE is thrown when trying to
create the implicit collect.
/*
* If the source type is a collection, then need there is an implicit
COLLECT operator.
* Note that this rule is not called after "->".
*/
if ((source != null) && source.getType() instanceof CollectionType) {
astNode = createImplicitCollect(
source,
(FeatureCallExp<C>) astNode,
env,
simpleNameCS);
}
The problem is that dummyInvalidLiteralExp is created if the feature is
not found, so a classCastException is thrown when doing the the typeCasting.
It seems to be a regression bug.
An extra question for you, why do you mention that 'Note that this rule
is not called after "->"'. How should it be interpreted the following
featureCallExp ?
aCollectonOfClasess->name
Cheers,
Adolfo.
|
|
|
| Re: Bug in OCLAbstractAnalyzer [message #56063 is a reply to message #56033] |
Fri, 16 May 2008 19:01  |
Adolfo Sanchez-Barbudo Herrera
Messages: 260
Registered: July 2009 |
Senior Member |
|
|
Hi Christian
Confirmed that It's a bug...
The OCL crash, if you access an in-existent property of a multivalued
property (or of a collection).
This should be the resolved bug which caused the regression:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=226083
I'll raise a bugzilla.
Cheers,
Adolfo.
Adolfo Sánchez-Barbudo Herrera escribió:
> Hi Christian,
>
> I have detected a problem when resolving a featureCallExp which will
> involve an implicit collect iterator.
>
> Think about getting a collection of names from a collection of Classes.
> for example the following expression should be useful
>
> aCollectionOfClasses.name
>
> because its implicit translated to
>
> aCollectionOfClasses->collect(i | i.name);
>
> If the name of a property doesn't exist, an NPE is thrown when trying to
> create the implicit collect.
>
> /*
> * If the source type is a collection, then need there is an implicit
> COLLECT operator.
> * Note that this rule is not called after "->".
> */
> if ((source != null) && source.getType() instanceof CollectionType) {
> astNode = createImplicitCollect(
> source,
> (FeatureCallExp<C>) astNode,
> env,
> simpleNameCS);
> }
>
> The problem is that dummyInvalidLiteralExp is created if the feature is
> not found, so a classCastException is thrown when doing the the
> typeCasting.
>
> It seems to be a regression bug.
>
> An extra question for you, why do you mention that 'Note that this rule
> is not called after "->"'. How should it be interpreted the following
> featureCallExp ?
>
> aCollectonOfClasess->name
>
> Cheers,
> Adolfo.
|
|
|
| Re: Bug in OCLAbstractAnalyzer [message #56089 is a reply to message #56033] |
Sun, 18 May 2008 18:06 |
Eclipse User |
|
|
|
Originally posted by: cdamus.zeligsoft.com
Hi, Adolfo,
I have resolved the bug. Note that, when you find bugs, you can just
raise them in bugzilla and save yourself some typing :-)
I don't think I am the author of the "note that this rule ..."
comment, but what it means is that the implicit collect iterator is
only created for dot-navigation ('.' operator). The arrow is applied
to values that already are collections (or are coerced to singleton
sets) so there is no collecting to do.
Note, also, that your example
aCollectionOfClases->name
is ill-formed OCL because 'name' is not an attribute of the collection
type. The arrow operator exclusively indicates features of
collections (which is why the rules for scalar coercion and implicit
collect are feasible). Currently, OCL only defines operations for
collection types, no attributes.
Cheers,
Christian
On Friday 05-16-2008 (07:18), Adolfo Sánchez-Barbudo Herrera wrote:
> Hi Christian,
> I have detected a problem when resolving a featureCallExp which will
> involve an implicit collect iterator.
> Think about getting a collection of names from a collection of
> Classes. for example the following expression should be useful
> aCollectionOfClasses.name
> because its implicit translated to
> aCollectionOfClasses->collect(i | i.name);
> If the name of a property doesn't exist, an NPE is thrown when
> trying to create the implicit collect.
> /*
> * If the source type is a collection, then need there is an implicit
> COLLECT operator.
> * Note that this rule is not called after "->".
> */
> if ((source != null) && source.getType() instanceof CollectionType)
> { astNode = createImplicitCollect(
> source,
> (FeatureCallExp<C>) astNode,
> env,
> simpleNameCS);
> }
> The problem is that dummyInvalidLiteralExp is created if the
> feature is not found, so a classCastException is thrown when doing
> the the
> typeCasting.
> It seems to be a regression bug.
> An extra question for you, why do you mention that 'Note that this
> rule is not called after "->"'. How should it be interpreted the
> following featureCallExp ?
> aCollectonOfClasess->name
> Cheers,
> Adolfo.
--
I'm trying a new usenet client for Mac, Nemo OS X.
You can download it at http://www.malcom-mac.com/nemo
|
|
|
Powered by
FUDForum. Page generated in 0.04401 seconds
] 
Search
Help
Register
Login
Home
