C++ generics example does not compile anymore

[cmnrd]

Compiling the C++ LF file ContextManager.lf in the examples repository throws the below exception.

This looks very odd. Why would a C++ program use classes from org.lflang.generator.c? Is this issue related to the recent efforts in supporting C generics?

0    [main] ERROR text.validation.CompositeEValidator  - Error executing EValidator
org.eclipse.emf.common.util.BasicEList$BasicIndexOutOfBoundsException: index=0, size=0
        at org.eclipse.emf.common.util.BasicEList.get(BasicEList.java:346)
        at org.lflang.generator.c.TypeParameterizedReactor.addTypeArgs(TypeParameterizedReactor.java:95)
        at org.lflang.generator.c.TypeParameterizedReactor.<init>(TypeParameterizedReactor.java:85)
        at org.lflang.generator.c.TypeParameterizedReactor.<init>(TypeParameterizedReactor.java:39)
        at org.lflang.generator.ReactorInstance.<init>(ReactorInstance.java:813)
        at org.lflang.generator.ReactorInstance.<init>(ReactorInstance.java:104)
        at org.lflang.ModelInfo.lambda$update$1(ModelInfo.java:116)
        at java.base/java.lang.Iterable.forEach(Iterable.java:75)
        at org.lflang.ModelInfo.update(ModelInfo.java:116)
        at org.lflang.validation.LFValidator.checkModel(LFValidator.java:589)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:568)
        at org.eclipse.xtext.validation.AbstractDeclarativeValidator$MethodWrapper.invoke(AbstractDeclarativeValidator.java:129)
        at org.eclipse.xtext.validation.AbstractDeclarativeValidator.internalValidate(AbstractDeclarativeValidator.java:337)
        at org.eclipse.xtext.validation.AbstractInjectableValidator.validate(AbstractInjectableValidator.java:72)
        at org.eclipse.xtext.validation.CompositeEValidator.validate(CompositeEValidator.java:151)
        at org.eclipse.emf.ecore.util.Diagnostician.doValidate(Diagnostician.java:299)
        at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:245)
        at org.eclipse.xtext.validation.CancelableDiagnostician.validate(CancelableDiagnostician.java:41)
        at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:200)
        at org.eclipse.emf.ecore.util.Diagnostician.validate(Diagnostician.java:142)
        at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:147)
        at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:125)
        at org.eclipse.xtext.validation.ResourceValidatorImpl.validate(ResourceValidatorImpl.java:91)
        at org.lflang.cli.CliBase.validateResource(CliBase.java:256)
        at org.lflang.cli.Lfc.invokeGenerator(Lfc.java:173)
        at org.lflang.cli.Lfc.doRun(Lfc.java:150)
        at org.lflang.cli.CliBase.run(CliBase.java:145)
        at picocli.CommandLine.executeUserObject(CommandLine.java:2026)
        at picocli.CommandLine.access$1500(CommandLine.java:148)
        at picocli.CommandLine$RunLast.executeUserObjectOfLastSubcommandWithSameParent(CommandLine.java:2461)
        at picocli.CommandLine$RunLast.handle(CommandLine.java:2453)
        at picocli.CommandLine$RunLast.handle(CommandLine.java:2415)
        at picocli.CommandLine$AbstractParseResultHandler.execute(CommandLine.java:2273)
        at picocli.CommandLine$RunLast.execute(CommandLine.java:2417)
        at picocli.CommandLine.execute(CommandLine.java:2170)
        at org.lflang.cli.CliBase.doExecute(CliBase.java:117)
        at org.lflang.cli.CliBase.cliMain(CliBase.java:109)
        at org.lflang.cli.Lfc.main(Lfc.java:137)
        at org.lflang.cli.Lfc.main(Lfc.java:127)

[petervdonovan]

This is certainly related to the recent changes related to generics and in particular to #1816 which was merged 2 days ago.

It is mostly the C target which uses ReactorInstance, and for convenience I added some code specific to the C target to ReactorInstance. However, ReactorInstance is used in other places (in the diagrams and in this case in the validator) which is why it is possible for this to happen.

I will work on a fix today.