steakhal added a comment. In D93224#2493515 <https://reviews.llvm.org/D93224#2493515>, @xazax.hun wrote:
> In D93224#2493434 <https://reviews.llvm.org/D93224#2493434>, @steakhal wrote: > >> How should I continue to get this working with CTU? > > We have two CTU modes. One loading the dump and the other loading from AST > source file. I assume that you refer to the former? Yes, I was referring to that. > Could you validate that this solution works for the latter? Sure, I suspect that will have the required PP events since the Preprocessor is parsing source code :D I'm going to check this just to be sure. > If we cannot make CTU fully functional, is it possible to at least make it > work for the current TU (as opposed to functions inlined from another TU)? This element of the patch stack implements exactly that. > While it would be great to have a fully working solution, not having macro > expansions in a single relatively narrow scenario might worth the trade-off > to get rid of the related bugs and throw out a half-baked reimplementation of > the preprocessor. Even in the CTU case, the main TU is still parsed via the main Preprocessor - hence we will track the macro expansions accordingly. I would definitely favor this 'option' instead of dropping this patch stack. I mean, it really fixes a bunch of crashes and expands macros much more accurately especially for the corner-cases. > If we really want to make it work for the CTU mode with dumps, we could dump > the macro expansions to a separate file together with the AST and read it > back for the error reporting. If we chose this path, the local `getExpandedMacro` function needs to be simplified. That would help Artem's dependency issue. CHANGES SINCE LAST ACTION https://reviews.llvm.org/D93224/new/ https://reviews.llvm.org/D93224 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
