This adjusts the way the headers kernel/{yosys,rtlil,register,log}.h
include each other to avoid the need of including headers outside of
include guards as well as avoiding the inclusion of rtlil.h in the
middle of yosys.h with rtlil.h depending on the prefix of yosys.h, and
the suffix of yosys.h depending on rtlil.h.
To do this I moved some of the declaration in yosys.h into a new header
yosys_common.h. I'm not sure if that is strictly necessary.
Including any of these files still results in the declarations of all
these headers being included, so this shouldn't be a breaking change for
any passes or external plugins.
My main motivation for this is that ccls's (clang based language server)
include guard handling gets confused by the previous way the includes
were done. It often ends up treating the include guard as a generic
disabled preprocessor conditional, breaking navigation and highlighting
for the core RTLIL data structures.
Additionally I think avoiding cyclic includes in the middle of header
files that depend on includes being outside of include guards will also
be less confusing for developers reading the code, not only for tools
like ccls.
It's a repeating pattern to print an error message tied to an AST
node. Start using an 'input_error' helper for that. Among other
things this is beneficial in shortening the print lines, which tend
to be long.
Previously this was tagged only with YS_ATTRIBUTE(noreturn), but not
YS_NORETURN, so it got lost in #2173, resulting in warnings in
frontends/ast/simplify.cc:
frontends/ast/simplify.cc:267:1: warning: function declared 'noreturn' should not return [-Winvalid-noreturn]
}
^
frontends/ast/simplify.cc:379:1: warning: function declared 'noreturn' should not return [-Winvalid-noreturn]
}
^
Upgrading to WASI SDK 11.0 caused the WASM build to fail because WASM
does not have signals. (Arguably Yosys was broken even before, it was
just broken silently.)
The workflow of debugging fatal pass errors in Yosys is flawed in
three ways:
1. Running Yosys under a debugger is sufficient for the debugger
to catch some fatal errors (segfaults, aborts, STL exceptions)
but not others (`log_error()`, `log_cmd_error()`). This is
neither obvious nor easy to remember.
2. To catch Yosys-specific fatal errors, it is necessary to set
a breakpoint at `logv_error_with_prefix()`, or at least,
`logv_error()`. This is neither obvious nor easy to remember,
and GDB's autocomplete takes many seconds to suggest function
names due to the large amount of symbols in Yosys.
3. If a breakpoint is not set and Yosys encounters with such
a fatal error, the process terminates. When debugging a crash
that takes a long time to reproduce (or a nondeterministic crash)
this can waste a significant amount of time.
To solve this problem, add a macro `YS_DEBUGTRAP` that acts as a hard
breakpoint (if available), and a macro `YS_DEBUGTRAP_IF_DEBUGGING`
that acts as a hard breakpoint only if debugger is present.
Then, use `YS_DEBUGTRAP_IF_DEBUGGING` in `logv_error_with_prefix()`
to obviate the need for a breakpoint on nearly every platform.
Co-Authored-By: Alberto Gonzalez <boqwxp@airmail.cc>
(IEEE1800-2017 section 20.11)
This PR allows us to use $info/$warning/$error/$fatal **at elaboration time** within a generate block.
This is very useful to stop a synthesis of a parametrized block when an
illegal combination of parameters is chosen.
The initial list of hits was generated with the codespell command
below, and each hit was evaluated and fixed manually while taking
context into consideration.
DIRS="kernel/ frontends/ backends/ passes/ techlibs/"
DIRS="${DIRS} libs/ezsat/ libs/subcircuit"
codespell $DIRS -S *.o -L upto,iff,thru,synopsys,uint
More hits were found by looking through comments and strings manually.
o Provide log_file_warning() and log_file_error() that prefix the log
message with <filename>:<lineno>: to be easily picked up by IDEs that
need to step through errors.
o Simplify some duplicate logging code in kernel/log.cc
o Use the new log functions in genrtlil.
