Open ayourtch opened 8 years ago
A further reduced testcase for this issue:
#define SOMEMACRO(v) (YYYYY)
#define _(a) SOMEMACRO (bi); _SOMEMACRO(ai);
_ (foo)
The parentheses around YYYYY are essential - if they are not there, the problem does not happen.
The problem is within the definition of the function that does the macro substitution - it matches on name that ends with a name of a macro that is already defined.
This patch seems to be taking care of it, I need to test it more extensively, I am not sure "^%w_" is the right class to match. But it gives the idea:
@@ -1268,9 +1301,13 @@ local function parseFunction(state, input)
-- build macro funcion
local func = function(input)
- return input:gsub(name.."%s*(%b())", function (match)
+ local f1 = function (match)
return replaceArgs(match, repl)
- end)
+ end
+ local f2 = function (match)
+ return match:sub(1,1)..replaceArgs(match:sub(2), repl)
+ end
+ return input:gsub("^"..name.."%s*(%b())", f1):gsub("[^%w_]"..name.."%s*(%b())",f2)
end
return name, func, repl
Cool, can you make a PR including the testcase?
Yeah, let me debug bit more, together with other fixes (I think it might add a regression), I will get the fixes for them in once I get lcpp to fully process my monster header correctly. Thanks!
Processing the below .h file (synthesized from real-world sequence of includes from the fd.io) with lcpp results in an infinite loop.
Using anything other than a single underscore for the macro definition in the last part, e.g. two underscores, results in successful processing.