This is necessary for a future patch, where we start using this macro in another function.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3009–3010 | One concern I have with this change is that the macro is using local variable names; it really would be better to have the macro content local to the function(s) where the variables are defined. Can you give more context about why this has to be called from another place? Maybe there's another way to solve the problem. |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3009–3010 | I've provided more context here: D93701. We can solve the problem with implicit use of local variables inside the macro by promoting them to macro parameters. |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3009–3010 | I like that idea. That approach also allows you to drop unused parameters entirely in PARSE_OPTIONS_WITH_MARSHALLING (only forward the parameters that get used). | |
3310–3311 | I like the idea of #undef'ing these macros to make their scope of use clear, but I'm not sure doing it at the end of file is adding a lot of value. Is there a way of moving the call sites for each to be next to each other in the file, so you can #define and then #undef in a more limited scope? E.g., // maybe other content... #define PARSE_OPTION_WITH_MARSHALLING(...) ... void f1(...) { /* use PARSE_OPTION_WITH_MARSHALLING */ } void f2(...) { /* use PARSE_OPTION_WITH_MARSHALLING */ } #undef PARSE_OPTION_WITH_MARSHALLING // maybe other content... #define GENERATE_OPTION_WITH_MARSHALLING(...) ... void f3(...) { /* use GENERATE_OPTION_WITH_MARSHALLING*/ } void f4(...) { /* use GENERATE_OPTION_WITH_MARSHALLING*/ } #undef GENERATE_OPTION_WITH_MARSHALLING // maybe other content... (If so, the code movement should be done in a separate NFC prep commit...) |
clang/lib/Frontend/CompilerInvocation.cpp | ||
---|---|---|
3009–3010 | I've dropped the unused parameters for the PARSE_ macro. D84673 does the same for the GENERATE_ macro. | |
3310–3311 | Yeah, limiting the scope where the macro is defined would be nice. I've moved things around and we'll be able to keep the GENERATE_ macro local to the function, while the PARSE_ macro will span only the two functions that'll make use of it. |
One concern I have with this change is that the macro is using local variable names; it really would be better to have the macro content local to the function(s) where the variables are defined.
Can you give more context about why this has to be called from another place? Maybe there's another way to solve the problem.