Change Details

This is the implementation of the inclusion of macro expansions into the plist output. This approach is very much different to what `HTMLRewrite` does -- the motivation behind this was that * I **really** wanted to avoid `const_cast`, * This patch aims to only expand macros relevant to the bugpath, so there's no point in lexing everything. Sadly, it seems like I couldn't get away with a solution not re-implementing parts of the preprocessor -- macro arguments are expanded manually and somewhat painfully, but I am very confident about it's stability and correctness. I included plenty of comments, maybe a little too much, but my reasoning was that the future maintainer of this code probably won't be expert on how to handle the preprocessor and the lexer, so judging from how much I struggled with it, I figured the extra explanation was justified. There are still some tests I'd like to perform, and some small details are still under debate (such as whether the kind of the plist entry will be `macro_expansion` or not), but the actual implementation of how macros are expanded won't be changed (unless I encounter a crash). **How this works:** * A new analyzer option was added to turn macro expansions on. * `BugReporter` will compact the bugpath when that flag is enabled, thus creating `PathDiagnosticMacroPiece`s. (fun fact: they were never created for plists before!) * When a macro is emitted, # a lexer is created to acquire the macro's name and arguments. # The actual definition of the macro can be acquired from the `Preprocessor`. # Should one of them be the parameter of the current macro, it has to be replaced manually with the information we gathered by lexing. # Should one of the tokens of the definition be a macro, it will be expanded recursively. The information about parameter is passed forth.

This is the implementation of the inclusion of macro expansions into the plist output. This approach is very much different to what `HTMLRewrite` does -- the motivation behind this was that * I **really** wanted to avoid `const_cast`, * This patch aims to only expand macros relevant to the bugpath, so there's no point in lexing everything. Sadly, it seems like I couldn't get away with a solution not re-implementing parts of the preprocessor -- macro arguments are expanded manually and somewhat painfully, but I am very confident about it's stability and correctness. I included plenty of comments, maybe a little too much, but my reasoning was that the future maintainer of this code probably won't be expert on how to handle the preprocessor and the lexer, so judging from how much I struggled with it, I figured the extra explanation was justified. There are still some tests I'd like to perform, and some small details are still under debate (such as whether the kind of the plist entry will be `macro_expansion` or not), but the actual implementation of how macros are expanded won't be changed (unless I encounter a crash). **How this works:** * A new analyzer option was added to turn macro expansions on. * `BugReporter` will compact the bugpath when that flag is enabled, thus creating `PathDiagnosticMacroPiece`s. (fun fact: they were never created for plists before!) * When a macro is emitted, # a lexer is created to acquire the macro's name and arguments. # The actual definition of the macro can be acquired from the `Preprocessor`. # Should one of them be the parameter of the current macro, it has to be replaced manually with the information we gathered by lexing. # Should one of the tokens of the definition be a macro, it will be expanded recursively. The information about parameters is passed forth.

This is the implementation of the inclusion of macro expansions into the plist output. This approach is very much different to what `HTMLRewrite` does -- the motivation behind this was that * I **really** wanted to avoid `const_cast`, * This patch aims to only expand macros relevant to the bugpath, so there's no point in lexing everything. Sadly, it seems like I couldn't get away with a solution not re-implementing parts of the preprocessor -- macro arguments are expanded manually and somewhat painfully, but I am very confident about it's stability and correctness. I included plenty of comments, maybe a little too much, but my reasoning was that the future maintainer of this code probably won't be expert on how to handle the preprocessor and the lexer, so judging from how much I struggled with it, I figured the extra explanation was justified. There are still some tests I'd like to perform, and some small details are still under debate (such as whether the kind of the plist entry will be `macro_expansion` or not), but the actual implementation of how macros are expanded won't be changed (unless I encounter a crash). **How this works:** * A new analyzer option was added to turn macro expansions on. * `BugReporter` will compact the bugpath when that flag is enabled, thus creating `PathDiagnosticMacroPiece`s. (fun fact: they were never created for plists before!) * When a macro is emitted, # a lexer is created to acquire the macro's name and arguments. # The actual definition of the macro can be acquired from the `Preprocessor`. # Should one of them be the parameter of the current macro, it has to be replaced manually with the information we gathered by lexing. # Should one of the tokens of the definition be a macro, it will be expanded recursively. The information about parameters is passed forth.