https://jira.opendaylight.org This file is an XML representation of an issue en-us 8.20.10 820010 22-06-2022 https://jira.opendaylight.org/browse/YANGTOOLS-1372 yangtools <p>StmtContext.Mutable does not expose the ability to conjure purely-effective statements, i.e. those which are truly inferred from overall context and do not have a DeclaredStatement counterpart.</p> <p>There are two use cases: implicit input/output statements in RPCs and Actions, which we cover through a rather ugly hack called StatementContextBase.appendImplicitSubstatement(). That part does still ends up creating a DeclaredStatement and also does not cover ModelStatement.argument() completely – for example it does not work for <a href="https://jira.opendaylight.org/browse/YANGTOOLS-1338" title="Generate ietf-restconf operations leaf statements" class="issue-link" data-issue-key="YANGTOOLS-1338"><del>YANGTOOLS-1338</del></a>, where the argument is a QName and we do not have a way to create a rawArgument String which would parse to what we need because we do not have the corresponding imports. Final deficiency is that it creates a SubstatementContext, i.e. having weird ties to declaration site.</p> <p>Expose a new method StmtContext.Mutable, which will create a truly effective-only statements. The argument should be an ImplicitStatementAwareSubstatementContext (or similar, as that is a mouthful), which is an additional interface implemented by things like InputStatementSupport and can work without a DeclaredStatement instance.</p> YANGTOOLS-1372

Add support for purely-effective substatements

New Feature High Resolved Done Robert Varga Robert Varga Tue, 30 Nov 2021 17:08:49 +0000 Thu, 26 Oct 2023 18:34:36 +0000 Thu, 16 Dec 2021 16:42:48 +0000 8.0.0 parser 0 1 <p>The current infra actually does something different – it is adding implicit statements, i.e. those still have a DeclaredStatement, but that declared statement shows up as being StatementOrigin.DECLARATION.</p> <p>In the reactor this is implied by the use of SubstatementContext for these statements. In individual statements supports (which support this) it shows up as special-casing in createDeclared(). In yang-model-ri this manifests as ImplicitStatements – which end up recognized in factory methods and ignored.</p> <p>This needs to work quite differently:</p> <ol> <li>we need an optional-to-implement UndeclaredStatementFactory, which will have an alternative createEffective() method, which does rely on DeclaredStatement</li> <li>we need an UndeclaredStmtCtx in the reactor, which will support Mutable.addEffectiveSubstatement(), with a better name of addUndeclaredSubstatement() – and there needs to be a checkArgument() to verify that the supplied support implements UndeclaredStatementFactory</li> <li>ImplicitStatements needs to be removed (along with the classes it references)</li> <li>We need to have an UndeclaredStatements to directly create EffectiveStatement instances</li> <li>Users of ImplicitStatements need to be migrated to implement UndeclaredStatementFactory</li> </ol> <p>The be-all end-all reason is that we do not have a reliable raw argument String, required for DeclaredStatements. The other is quick consistency checks to an opt-in behaviour – i.e. RpcStatementSupport can only use implicit input statements because InputStatementSupport knows how to deal with them – and that capability is not exposed as a trait (such as UndeclaredStatementFactory ), it is just an implementation detail. The third, minor one, is that we create bogus objects to dance around StatementContextBase's requirement of having a DeclaredStatement instance.</p> <p>Okay, this is a bit more complicated and boils down to ModelStatement.statementOrigin() and its interpretation in DeclaredStatement vs EffectiveStatement. Part of this is an implementation quirk of statement loading, where we end up inserting UndeclaredCaseStatement into DeclaredChoiceStatement:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>choice foo { case bar; container baz; } </pre> </div></div> <p>ends up looking like this:</p> <div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent"> <pre>ChoiceStatement foo DeclaredCaseStatement bar UndeclaredCaseStatement baz Container baz </pre> </div></div> <p>The difference between Declared and Undeclared CaseStatements is only statementOrigin(). We have to account for this in yang-model-export and inline StatementOrigin.CONTEXT statements' substatements.</p> <p>We therefore need to perform a bit of house cleaning:</p> <ol> <li>eliminate generation of UndeclaredCaseStatement and instead inline Container baz, just as it is declared (<a href="https://jira.opendaylight.org/browse/YANGTOOLS-1383" title="Do not emit UndeclaredCaseStatements" class="issue-link" data-issue-key="YANGTOOLS-1383"><del>YANGTOOLS-1383</del></a>)</li> <li>move ModelStatement.statementOrigin() to EffectiveStatement, eliminating Undeclared* DeclaredStatements (<a href="https://jira.opendaylight.org/browse/YANGTOOLS-1384" title="Remove ModelStatement.statementSource()" class="issue-link" data-issue-key="YANGTOOLS-1384"><del>YANGTOOLS-1384</del></a>)</li> </ol> <p>Once that is done, we can roll out proper specialized implementations.</p> Blocks YANGTOOLS-1338 YANGTOOLS-1270 YANGTOOLS-1383 YANGTOOLS-1384 Development Rank 0|i040un: