[YANGIDE-5] No editor view error marker for invalid recursive container definition. Created: 05/May/16  Updated: 19/Oct/17

Status: Open
Project: yangide
Component/s: General
Affects Version/s: unspecified
Fix Version/s: None

Type: Bug
Reporter: David M. Karr Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Operating System: All
Platform: All


External issue ID: 5849

 Description   

Most syntactical and semantic errors are properly noticed and render proper editor view markers.

I accidentally discovered an odd example that is syntactically correct, but semantically wrong, and the Yang parser fails to compile it, but it doesn't render an editor view error marker.

In particular, a yang module with the following pattern will do this:
-----------------
grouping machine-def {
container factory

{ uses baz:machine-def; }

container factory2

{ uses machine-def; // line 24 }

}
----------------

This produces the following stack trace in the problems view, but no editor marker:
---------------------
yang-to-sources: Unable to parse yang files from /home/opnfv/workspace-yangidetest/yangproject2/src/main/yang (org.opendaylight.yangtools:yang-maven-plugin:1.0.0-SNAPSHOT:generate-sources:generate-sources:generate-sources)

org.apache.maven.plugin.MojoExecutionException: yang-to-sources: Unable to parse yang files from /home/opnfv/workspace-yangidetest/yangproject2/src/main/yang
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.processYang(YangToSourcesProcessor.java:200)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.execute(YangToSourcesProcessor.java:93)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesMojo.execute(YangToSourcesMojo.java:116)
at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:134)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:331)
at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1362)
at org.eclipse.m2e.core.internal.embedder.MavenImpl$11.call(MavenImpl.java:1)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
at org.eclipse.m2e.core.internal.embedder.MavenImpl.execute(MavenImpl.java:1360)
at org.eclipse.m2e.core.project.configurator.MojoExecutionBuildParticipant.build(MojoExecutionBuildParticipant.java:52)
at org.opendaylight.yangide.m2e.yang.YangBuildParticipant.build(YangBuildParticipant.java:97)
at org.eclipse.m2e.core.internal.builder.MavenBuilderImpl.build(MavenBuilderImpl.java:137)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:172)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$1.method(MavenBuilder.java:1)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1$1.call(MavenBuilder.java:115)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:112)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod$1.call(MavenBuilder.java:105)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.executeBare(MavenExecutionContext.java:176)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:151)
at org.eclipse.m2e.core.internal.embedder.MavenExecutionContext.execute(MavenExecutionContext.java:99)
at org.eclipse.m2e.core.internal.builder.MavenBuilder$BuildMethod.execute(MavenBuilder.java:86)
at org.eclipse.m2e.core.internal.builder.MavenBuilder.build(MavenBuilder.java:200)
at org.eclipse.core.internal.events.BuildManager$2.run(BuildManager.java:734)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:205)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:245)
at org.eclipse.core.internal.events.BuildManager$1.run(BuildManager.java:300)
at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42)
at org.eclipse.core.internal.events.BuildManager.basicBuild(BuildManager.java:303)
at org.eclipse.core.internal.events.BuildManager.basicBuildLoop(BuildManager.java:359)
at org.eclipse.core.internal.events.BuildManager.build(BuildManager.java:382)
at org.eclipse.core.internal.events.AutoBuildJob.doBuild(AutoBuildJob.java:144)
at org.eclipse.core.internal.events.AutoBuildJob.run(AutoBuildJob.java:235)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)
Caused by: org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException: Grouping '(http://acme.example.com/system?revision=2007-06-09)machine-def' was not resolved. [at META-INF/yang/acme-system.yang:24:9]
at org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException.throwIf(InferenceException.java:47)
at org.opendaylight.yangtools.yang.parser.stmt.rfc6020.UsesStatementImpl$Definition$1.prerequisiteFailed(UsesStatementImpl.java:106)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.ModifierImpl.failModifier(ModifierImpl.java:91)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.SourceSpecificContext.failModifiers(SourceSpecificContext.java:290)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.addSourceExceptions(BuildGlobalContext.java:214)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.completePhaseActions(BuildGlobalContext.java:283)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.BuildGlobalContext.buildEffective(BuildGlobalContext.java:175)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.CrossSourceStatementReactor$BuildAction.buildEffective(CrossSourceStatementReactor.java:105)
at org.opendaylight.yangtools.yang.parser.stmt.reactor.CrossSourceStatementReactor$BuildAction.buildEffective(CrossSourceStatementReactor.java:123)
at org.opendaylight.yangtools.yang2sources.plugin.YangToSourcesProcessor.processYang(YangToSourcesProcessor.java:169)
... 35 more
---------------------

Note that in the code sample, the "machine-def" grouping is RECURSIVELY referenced, which can't possibly be valid.

Obviously a contrived scenario, but also wrong. It needs to produce a proper error marker.

The key portion of the stacktrace is the following:
---------------
Caused by: org.opendaylight.yangtools.yang.parser.spi.meta.InferenceException: Grouping '(http://acme.example.com/system?revision=2007-06-09)machine-def' was not resolved. [at META-INF/yang/acme-system.yang:24:9]
-----------------

Line 24 in the code sample is marked, showing what line should get the error marker. It would be great if the error could be more intelligent, knowing that it was inside the definition of the mentioned grouping, so the error could refer to the fact that you can't reference a component from inside the component.



 Comments   
Comment by David M. Karr [ 05/May/16 ]

Curiously, if at this point I go to some random line in the file and add "x" to the end of a line, it immediately puts a red marker on that line, and if I then remove the "x", that error marker goes away, and a new error marker appears on line 24, saying "Grouping 'machine-def' not found", exactly what it should have said in the first place (again, unless we can't make the message a little smarter).

Generated at Wed Feb 07 20:48:25 UTC 2024 using Jira 8.20.10#820010-sha1:ace47f9899e9ee25d7157d59aa17ab06aee30d3d.