'// Some setup
#define prefix foo
'// Works (No error during compile, -pp generated code is fine)
#define param prefix#1
dim as integer param
'// Breaks (Error during compile, -pp generated code is fine)
#macro broken(param)
dim as integer param
#endmacro
broken(prefix#2)
'// The '1' and '2' can be anything, including other defines, causing different and incorrect errors
'// Breaks (Error during compile, -pp generated code is fine)
broken(prefix#AAA)
'// Breaks (Error during compile, -pp generated code is fine)
broken(prefix#prefix#1)
'// Not using a macro.. almost.. works as expected
'// Works (No error during compile, -pp generated code is fine)
#undef param
#define param prefix#BBB
dim as integer param
#undef param
'// This breaks and creates 'fooprefix' when 'foofoo' is expected
'// Breaks (No error during compile, -pp generated code is wrong)
#define param prefix#prefix#2
dim as integer param
'// Trying to use ## Concat instead of # Stringize breaks things even further
#define prefix foo
#define param prefix#1
dim as integer param
The # is being consumed as a suffix, but no error thrown. Is that a problem of suffix handling? ... only a little, the real problem is much worse and leads to other non-suffix related weirdness in other situations.
When the parser asks the lexer for the next token, there's a whole bunch of options that can be specified to indicate what should be expected next. The parser usually doesn't explicitly state the options and lexer assumes whatever options were used last should be used again.
fxm wrote: ↑May 02, 2024 16:38
Me too, but I regret that Discord takes priority over the Forum (I suppose the question was asked on both).
For me, the forum is still priority for communication about freebasic. Discord offers convenience for live conversation but if I gave discord priorty I would get nothing else done so for me it's typically only running in the background.