Cross-resource ereference handling improvements

[OszkarSemerath]

In some cases the type definitions in the parameter list doesn't work correctly.

For example there is a pattern that finds the classifier constrains in another pattern. The source files are here: https://gist.github.com/3225406

The target pattern is:

pattern schools(S) =
{
    School(S);
}

Here is the pattern to find the constraints (the body isn't interesting):

pattern ClassConstrainInDirectBodyByEntities(pat:Pattern, body:PatternBody, variable:Variable, class:EClassifier, constraint:EClassifierConstraint) =
{
    // ...
}

This pattern correctly finds the one match.

I have made the following pattern where the declaration is the same as in ClassConstrainInDirectBodyByEntities, and calls the first:

pattern ClassConstrainInDirectBodyByEntities2(pat:Pattern, body:PatternBody, variable:Variable, class:EClassifier, constraint:EClassifierConstraint) =
{
    find ClassConstrainInDirectBodyByEntities(pat,body,variable,class,constraint);
}

This should give the same match as in the first case, but it doesn't have any.

So I deleted the EClassifier type of the parameter class, like this:

pattern ClassConstrainInDirectBodyByEntities3(pat:Pattern, body:PatternBody, variable:Variable, class/*:EClassifier*/, constraint:EClassifierConstraint) =
{
    find ClassConstrainInDirectBodyByEntities(pat,body,variable,class,constraint);
}

And the pattern works correctly.

I tried it with the EObject type and that doesn't work either.

pattern ClassConstrainInDirectBodyByEntities4(pat:Pattern, body:PatternBody, variable:Variable, class:EObject/*:EClassifier*/, constraint:EClassifierConstraint) =
{
    find ClassConstrainInDirectBodyByEntities(pat,body,variable,class,constraint);
}

Patterns with similar features worked for me before 26 of July.

[bergmanngabor]

I suspect this is a derived feature issue.

PatternBody.variables is a derived containment edge, registered as well-behaving. Still, somehow the containment traversal skips this branch, and therefore local variables will be unavailable in IQBase (is pre-initialization required here?). Their incoming VariableReference.variable edge, however, is traversed correctly, and therefore the first pattern finds the match. The reason of discrepancy between the matchers is the following: the second pattern would re-assert the type as "Variable", but only the pattern parameters are visible to IQBase, local variables aren't, so this rejects the match of the first pattern.

I will try to look into the internal workings of these derived edges in the absence of @ujhelyiz - it seems that PatternBody.variables is not even visible to eContents() !

[bergmanngabor]

In fact, the reference in question is not supposed to be well-behaving. @abelhegedus has committed a fix that will stop the registry from misreporting this: 658a059bd05d4ba97fcb596e354ae6b05427d026.

Now the patterns have no matches. TODO:

• proper error indication if pattern matching fails due to derived features
• smoothing out the well-behavedness in this particular case
• workaround for eContents() which is a separate issue

[bergmanngabor]

update: now the problem is solved temporarily, so we can finally reproduce Oszkár's problem... I guess.

[bergmanngabor]

I could reproduce this phenomenon with the Query Explorer, but I believe it is not a bug.

• I loaded an .eiq file with "Load as model"
• QE installed the ReteEngine on PatternModel as model root
• this subtree does not contain the class, so the extra filter in ClassConstrainInDirectBodyByEntities2 and ClassConstrainInDirectBodyByEntities4 will eliminate it.

So far, everything works according to design. The question is whether we could make it a little bit more predictable for the user. Any suggestions on better handling of the boundary of the matcher scope?

[istvanrath]

Decisions:

• decision 1: load resourceset should be the default in all relevant cases, see #261
• decision 2: pattern matcher should not consider cross-scope edges as part of the match set
• decision 3: (optionally) implement a runtime warning to indicate when cross-scope edges are attempted to be matched

[ujhelyiz]

@szabta89 Please, ensure decision 1.

[szabta89]

Load ResourceSet is the default behaviour (00755bfa7b65e10e8939b0054b5f25ae1db2025a and f7a85d4d39fe4a9b73fd56da2bb38a97353247cc)

[istvanrath]

Moved to Eclipse: https://bugs.eclipse.org/bugs/show_bug.cgi?id=398907