Fusing macro argument eats up whitespace

[tudortimi]

I have the following code:

class some_class;
endclass

`define some_macro(NAME) \
    class extension_for_``NAME`` extends some_class; \
    endclass \

`some_macro(foo)

I get the following error:

%Error: test.sv:8:37: syntax error, unexpected TYPE-IDENTIFIER, expecting ';'
    8 |     class  extension_for_fooextends some_class; 
      |                   

You can see that Verilator is not leaving a between foo and extends.

I'm using Verilator 5.024 and running with verilator test.sv --binary.

[wsnyder]

Surprising this was missed.

Might you be able to look at the V3PreProc code to see what's causing this and prepare a pull request? The t_preproc.v test should be updated to have this case in it.

[tudortimi]

This sounds like it would be simple enough. Sure, assign it to me.

[tudortimi]

I had a look at the LRM and the trailing `` aren't needed for fusing class_for_ and NAME. In this case, extension_for_``NAME would be enough.

I'm not really 100% sure what NAME`` something should produce in this case. The LRM states:

A `` delimits lexical tokens without introducing white space [...].

Is considered a lexical token? Should it simply expand to the value of NAME followed by something, as if simply defining NAME something? (Other tools seem to do this.)

[tudortimi]

Assuming we want to fuse like in the above post, like all the other tools do, I had a look at the code and think I kinda got it.

I have the following macro in the test:

`define with_space_before_suffix(f) f`` suffix_after_space
`with_space_before_suffix(arg)

I see the preprocessor recognizing the arg`` part:

After arg gets put onto the stack and the state is set to JOIN, it hits the whitespace:

This line causes the space to be emitted and keeps the state as JOIN. (I'm guessing it then somehow jumps into the GETFETC part, which takes care of outputting the space, but didn't really follow how it gets there.) This explains why the expansion starts with arg (with space) and not arg (no space).

The next token is suffix_after_space, which also gets pushed to the stack as the RHS of the JOIN (the state left over):

This is because it still thinks it's in the JOIN that the should have actually ended.

I don't really know what code is needed to fix this, but I'm guessing there's some extra case needed to handle WHITE when in JOIN here:

[wsnyder]

Your analysis seems correct, including likely some new text is needed to handle WHITE when in JOIN in your post above.