Most pre-processor errors are flagged to the main compiler by a comment
at the end of the pre-processed output. But certain errors, such as
failing to find or open an include file, cause the pre-processor to
exit immediately, which bypassed the generation of that comment. So
we need to also generate that comment for all early-exit cases.
This fixes issue #1104.
Make sure that comments spanning multiple lines are supported in multi-line
macros. Since the lexer parses line by line we need a flag to track whether
a multi-line comment is currently active.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
A '*' or '/' directly following a C-style comment in a macro currently
triggers the detection of the start of another comment. Fix this by first
looking for a '/' that should start the comment.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
macro_start_args truncates def_buf, but does not check to ensure that
someone has allocated def_buf first. This will cause a null pointer
dereference if the first access to def_buf while parsing a file is a
macro invocation. Fix this by avoiding truncating def_buf if it is NULL,
as it is effectively already truncated.
Fixes: 680196953 ("Add support for text macros with arguments.")
Signed-off-by: Sean Anderson <seanga2@gmail.com>
To correctly restore the file name and line number after including a
file or expanding a macro, the preprocessor needs to be aware of the
changes introduced by `line directives. The `line directive still
needs to be passed on to the main compiler so it can track the
changes too.
To avoid duplicate error messages, the preprocessor silently ignores
invalid `line directives, relying on the main compiler to report the
errors.
The IEEE standard does not clearly state whether the `` directive is applied
before or after embedded macros are expanded. Other simulators vary in their
behaviour. For maximum compatibility, this fix adopts the behaviour found in
Verilator, where `prefix``suffix expands to <prefix>suffix if prefix is a
defined macro, otherwise it expands to <prefixsuffix> (where <...> is the
expanded macro text). Other simulators show this behaviour in at least some
circumstances.
Given a macro definition like this:
`define name `macro``text
the preprocessor should expand `macro, not `macrotext, when it expands
`name. This also ensures that
`define name(p,s) p``_``s
`define PREFIX my_prefix
`define SUFFIX my_suffix
`name(`PREFIX, `SUFFIX)
expands to
my_prefix_my_suffix
as the user would expect.
In PR #300, @xdch47 pointed out a stable way to fix parallel
installation problems.
This fix applied the method, thanks!
Signed-off-by: Huang Rui <vowstar@gmail.com>
As for parentheses, we need to ignore commas within a pair of braces
when parsing a macro argument, e.g. `MACRO({a,b}) has one argument.
This fix is a little crude in that it doesn't distinguish between
parentheses and braces, e.g. it will accept {a,b). But any errors
like that will be caught by the compiler proper.
Predefined macros get stored in the precompiled macro file that gets
read back in when processing library files. This means the predefined
macros get processed twice. We need to skip the check in this case.
A common use case (prior to the introduction of localparam) was to
use macros to define constant values, and to put global constant
values in an include file that gets included by each source file.
This will generate a lot of spurious warnings if we warn about all
redefinitions. Make this new option the default for -Wall.
Verilog spec has a very nasty system of macros jumping from
file to file, resulting in a global macro scope. We abosolutely
MUST track macro redefinitions and warn user about them.
Signed-off-by: Andrew Andrianov <andrew@ncrmnt.org>
The existing support for ``, `", and `\`" did not work in nested macro
definitions. Note that the new implementation only detects and replaces
these sequences inside the macro text (as required by the IEEE standard),
whereas the old implementation would detect and replace them anywhere in
the source files.