Unable to use verilog-warn-fatal in local variables section when using verilog-batch-auto

[Rich-Cloutier]

I have found a problem when using batch mode (verilog-batch-auto) and trying to set verilog-warn-fatal in the local-variables section of a SystemVerilog file. The inclusion of verilog-warn-fatal will cause processing of the local variables section to be abandonded.

Conditions to see the issue

1. Run verilog-batch-auto in emacs --batch mode
2. use a SystemVerilog file with a local variables section that contains:

   // Local Variables:
   // verilog-library-directories:("." "lib_area/")
   // verilog-warn-fatal:t

   Then while executing the command verilog-batch-auto, verilog-mode will be unable to find the modules defined in the directories specified for the verilog-library-directories, because the setting of verilog-library-directories will not be processed, because verilog-warn-fatal is not considered a safe local variable. Since it is not considered safe, the batch mode emacs abandons processing of local variables because there was no possible response to the question about using unsafe local variables. A potential fix for this problem is to apply something like this patch to verilog-mode.el

   508,509c508,515
   < (defvar verilog-warn-fatal nil
   <   "Non-nil means `verilog-warn-error' warnings are fatal `error's.")
   ---
   > ;; (defvar verilog-warn-fatal nil
   > ;;   "Non-nil means `verilog-warn-error' warnings are fatal `error's.")
   > 
   > (defcustom verilog-warn-fatal nil
   >   "Non-nil means `verilog-warn-error' warnings are fatal `error's."
   >   :group 'verilog-mode-auto
   >   :type 'boolean)
   > (put 'verilog-warn-fatal 'safe-local-variable #'verilog-booleanp)

Even with this patch you will still get the message from emacs: Making verilog-warn-fatal buffer-local while locally let-bound!, because verilog-warn-fatal is a let variable in verilog-batch-auto. So I don't know if there is a better alternative fix for this problem.

Details for reproduction of problem: Versions: Emacs : GNU Emacs 27.1 (build 2, x86_64-pc-linux-gnu, X toolkit, Xaw scroll bars) of 2020-09-24 Package: verilog-mode v2022-07-17-dad7c92-vpo

Two SystemVerilog source files, in specific directories: File1: ./foo.sv

    module foo(input clock, input [7:0] in1_top, in2_top, output reg [7:0] out1_top);
    /*AUTOUNUSED*/
    /*AUTOLOGIC*/
    /*AUTOREGINPUT*/
    /*AUTOWIRE*/

    /* bar AUTO_TEMPLATE (
           .b\(.*\) (unused),
           .\(.*\) (@"(if (equal vl-dir \\"input\\") (concat vl-width \\"'b0\\") (if (equal vl-dir \\"output\\") (concat vl-name \\"_top\\") \\"\\/*inout not supported*\\/\\" ) )"),
      );
     */

       bar u1(
          /*AUTOINST*/);
    endmodule

    endmodule
    // Local Variables:
    // verilog-library-directories:("." "lib_area/")
    // verilog-auto-template-warn-unused:t
    // verilog-warn-fatal:t
    // End:

File2: ./lib_area/bar.sv

    module bar(input clock, input [7:0] in1, in2, in3, output reg [7:0] out1, inout io1);

       always @(posedge clock)
         begin: main
           out1 <= in1 & in2;
         end
    endmodule

Run emacs in batch mode:

    ~/Experiment> emacs -q -nsl -l ~/lib/lisp/verilog-mode.el --batch foo.sv -f verilog-batch-auto

and you will see the output:

    %Error: /home/user01/Experiment/foo.sv:20: Can t locate  bar  module definition
        Check the verilog-library-directories variable.
        I looked in (if not listed, doesn t exist):
        /home/user01/Experiment/foo.sv

[wsnyder]

The original thinking was verilog-warn-fatal would be globally set, so not in Local Variables. Are you setting it in Local Variables only due to batch mode, or for another reason (e.g. when running interactively on separate files)?

I think your suggestion to make it safe is reasonable, though I'd want to figure out how to avoid that warning, either by suppressing it, or with a new variable that only that "let" sets.

[Rich-Cloutier]

Some of our use of verilog-auto is for batch mode scripting run by services and may not be run as a user who has setup an .emacs file. We wanted those scripts to error out (not just warn) if there was an issue with one of the templates. So for this use case we decided that all configuration information should be in the local variables section (almost as a boilerplate section) in our source SystemVerilog files.

[wsnyder]

Should work now, thanks for the report & fix.