[GitHub] [daffodil] stevedlawrence commented on a change in pull request #772: Clear diagnostics (warnings) on saveParser.

[GitBox <gi...@apache.org>]

stevedlawrence commented on a change in pull request #772:
URL: https://github.com/apache/daffodil/pull/772#discussion_r824807833



##########
File path: daffodil-tdml-processor/src/main/scala/org/apache/daffodil/tdml/processor/DaffodilTDMLDFDLProcessor.scala
##########
@@ -128,11 +128,12 @@ final class TDMLDFDLProcessorFactory private (
         if (useSerializedProcessor) {
           val os = new java.io.ByteArrayOutputStream()
           val output = Channels.newChannel(os)
-          p.save(output)
+          p.save(output, clearDiagnostics = false) // TDML runner wants to preserve all diagnostics

Review comment:
       As an alternate approach, what are your thoughts on making it so we never clear diagnostics from a DataProcessor, whether it be serialized or not. The benefit is that when you reload a DataProcessor, you still have access to those compile time diagnostics if you want them. So if you want to know if there were any warnings when you compiled some old DataProcessor, you can easily figure that out.
   
   And then to avoid extraneous diagnostics during parse/unparse we change it so DataProcessor diagnostics do not carry over to the ParseResult diagnostics. So there are two completely separate buckets of diagnostics--compile time and runtime. If a user needs access to the compile time diagnostics (like the TDML runner) , it needs to pull them off of the DataProcessor.
   
   In fact, maybe we already do this and the compile-time and run-time diagnosics are already separate? Maybe the fix is to just make it so when we `reload()` we don't output diagnostics from the DataProcessor? In other words, we remove this line:
   
   https://github.com/apache/daffodil/blob/main/daffodil-cli/src/main/scala/org/apache/daffodil/Main.scala#L595
   
   That only affects the CLI. I'm not sure if that is where you were seeing too much diagnostic information.




-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@daffodil.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org