Refering instantiated reactors from the inherited reactor.

[Jakio815]

When the upper reactor (Parent) instantiates an reactor, it is not accessible from the extended reactor.

In the example below, the parent_sub reactor is not accessible from the extended reactor Child.

target C

reactor sub {
  input sub_in : int
}

reactor Parent {
  parent_sub = new sub()
}

reactor Child extends Parent {
  input child_input: int
  child_sub = new sub()

  child_input ->parent_sub.sub_in // Doesn't work.
  child_input-> child_sub.sub_in
}

Is this a bug or intended behavior?

[edwardalee]

Definitely a bug. Probably somewhere there is a call to Reactor.getInstantiations that should be ASTUtils.allInstantiations(Reactor).

[Jakio815]

It looks like the instantiation is working properly.

I found this code in ReactorInstance.java

      // Instantiate children for this reactor instance.
      // While doing this, assign an index offset to each.
      for (Instantiation child : ASTUtils.allInstantiations(reactorDefinition)) {
        var childInstance = new ReactorInstance(child, this, reporter, desiredDepth, reactors);
        this.children.add(childInstance);
      }

I think it is getting instantiated properly.

Is there a possibility that it fails on a checking or validation stage? So I mean it did get instantiated on the generation, but maybe the compiler refuses it?

[hokeun]

@Jakio815 Dongha, can you share your progress on the investigation here as we discussed today?

[Jakio815]

In ReactorInstance.java,

public ReactorInstance(
... {
  ...
  establishPortConnections();
  ...

the establishPortConnections() reports an error.

private void establishPortConnections() {
    for (Connection connection : ASTUtils.allConnections(reactorDefinition)) {
      List<RuntimeRange<PortInstance>> leftPorts =
          listPortInstances(connection.getLeftPorts(), connection);
      Iterator<RuntimeRange<PortInstance>> srcRanges = leftPorts.iterator();
      List<RuntimeRange<PortInstance>> rightPorts =
          listPortInstances(connection.getRightPorts(), connection);
      Iterator<RuntimeRange<PortInstance>> dstRanges = rightPorts.iterator();

The listPortInstances() fails, not being able to find a port.

So, it looks like before the code came to this point, it did not create the AST properly.

I am investigating where reactorDefinition's Connection is created in the first place.

[Jakio815]

The errors above happened during validateResource().

  private void invokeGenerator(List<Path> files, Path root, GeneratorArguments args) {
    for (Path path : files) {
      path = toAbsolutePath(path);

      String outputPath = getActualOutputPath(root, path).toString();
      this.fileAccess.setOutputPath(outputPath);

      final Resource resource = getResource(path);
      if (resource == null) {
        reporter.printFatalErrorAndExit(
            path + " is not an LF file. Use the .lf file extension to" + " denote LF files.");
      } else if (federated) {
        if (!ASTUtils.makeFederated(resource)) {
          reporter.printError("Unable to change main reactor to federated reactor.");
        }
      }

      validateResource(resource);
      exitIfCollectedErrors();

So I suspect that the parsing is the problem, somewhere inside getResource().

[Jakio815]

I'm now pretty sure that creating the Connection inside the reactorDefinition is the problem.

However, I can't find where the Connection is getting created. I think it is created in Xtext, but it's confusing.

@edwardalee Can you give me any advice where to find the lfc parsing the lf code?

[edwardalee]

I suspect the problem is with the scope provider, not the parser.

One line that is almost certainly an error is this one in LFScopeProviderImpl.java:

var instances = new ArrayList<Instantiation>(reactor.getInstantiations());

This should be:

var instances = new ArrayList<>(allInstantiations(reactor));

with the following import added at the top of the file:

import static org.lflang.ast.ASTUtils.allInstantiations;

However, this fix does not solve the problem, so there are more errors.

One thing I find extremely odd is that we get this error:

lfc: error: Couldn't resolve reference to Instantiation 's1'.
 --> src/Junk.lf:15:23
   |
14 | 
15 |   child_input_port -> s1.p // Doesn't work.
   |                       ^^ Couldn't resolve reference to Instantiation 's1'.
   |
16 |   child_input_port-> s2.p 

However, the string "Couldn't resolve reference to Instantiation" is nowhere in the tree!
If anyone can figure out where this error message is coming from, maybe this would be easy to track down.

[Jakio815]

I agree. I also couldn't find where that message is from Couldn't resolve reference to Instantiation. That's why I thought it came from another library the lfc is using.

[edwardalee]

Note: This bug report belongs in the lingua-franca repo, and is related to this one: lf-lang/lingua-franca#1748

It seems that there is an XText problem related to this. XText has a LazyLinkingResource that, apparently, lazily tries to find links in the grammar. A link is specified in the LinguaFranca.xtext file using square brackets, as follows:

VarRef:
    (variable=[Variable] | container=[Instantiation] '.' variable=[Variable]
    | interleaved?='interleaved' '(' (variable=[Variable] | container=[Instantiation] '.' variable=[Variable]) ')') ('as' (alias=ID))?

Here, a VarRef can have the form instantiation.port, as in your example, in which case port is a reference to an Input object. A problem, I think, is that XText tries to resolve the port part of the link before the instantiation part, and when it does this, the instantiation is not known. So our LFScopeProviderImpl can't figure out which reactor provide as the scope.

I'm trying to find a workaround.

[edwardalee]

It turns out that the problem was indeed with our scope provider. I have pushed a fix and have PR: lf-lang/lingua-franca#2500 that I believe will fix these problems.