-
Notifications
You must be signed in to change notification settings - Fork 73
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix ProcessorFactory.withDistinguishedRootNode and isError
When calling withDistinguishedRootNode, we copy the ProcessorFactory and replace the root spec with the new node. When we do this, we also copy the existing SchemaSet. But this SchemaSet was created with the previous root spec, which means withDistinguishedRootNode doesn't actually do anything. Fortunately, there is a workaround which is to pass in the root name/namspace to the compileSource/File functions, so that the root spec is available when the SchemaSet is created, and avoid withDistinguishedRootNode entirely. But to fix this, this modifies withDistinguishedRootNode to not copy the SchemaSet, so a new SchemaSet is created and initialized with the correct root spec. Each ProcessorFactory now has a unique SchemaSet instance with the correct root name and namespace. This also discovered cases in the Compiler.compileSourceInternal and JAPI/SAPI compileFile functions where they called isError on the newly created ProcessorFactory before returning it to the caller. This meant that the SchemaSet inside the ProcessorFactory would be forced to be created, even though it might never be used, like in the case of withDistinguishedRootNode being called and a different SchemaSet being created. Really the isError function should only ever be called by the user when they are ready for the object to be evaluated, and not forced by Daffodil internals. This ensures we avoid unnecessary work until the user is ready, since isError is what eventually causes lazy vals to be evaluated. However, this does mean that if a user doesn't check isError they might get exceptions/assertions, but it is well documented in the JAPI/SAPI that isError should be checked before calling other functions. This also means that some debug logging that relies on knowing that status of isError must be moved elsewhere, since the user might not have called isError yet. This also discovered instances in the TDMLRunner and CLI where we queried diagnostics before checking isError--isError should always be done first, which is fixed. That said, this also modifies ProcessorFactory.getDiagnostics so that it calls isError before returning the diagnostics. This way if user calls getDiagnostics without first calling isError (like we used to do in the TDMLRunner and CLI), the compilation work will be done and correct diagnostics generated. Without this, there would be no diagnostics because no work would be done yet. Although technically a user should call isError before asking for diagnostics, there may be cases where users don't, so this allows that to keep working as expected. This is similar to how onPath calls isError even if a user doesn't. DAFFODIL-2864, DAFFODIL-697
- Loading branch information
1 parent
d66a8b4
commit b897694
Showing
8 changed files
with
136 additions
and
32 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters