Michael137 wrote: > But if it'd require substantial reengineering to clang to get this working - > this seems an unfortunate regression to carry in the interim, and it might be > worth reverting to the previous (differently buggy, but at least > work-around-able) behavior.
To clarify, the regression @dwblaikie reported in https://github.com/llvm/llvm-project/issues/79668 was introduced in https://github.com/llvm/llvm-project/pull/74786, not in this current PR. IIUC, this PR just *partially* fixed https://github.com/llvm/llvm-project/issues/53904? > The new flow could be: > > * any struct/class gets created as a forward declaration and has the external > AST source enabled > * the external AST calls to complete the type when needed by expression > parser or LLDB APIs > * we complete the type > * we leave the external AST enabled so we can get called for contained types > > The last item here would require modifications to clang which could be > debugger specific changes that are only enabled in a special debug compiler > mode so they don't affect the actual compiler. Thoughts? Following overview of the clang<->lldb call-chain might be useful: https://github.com/llvm/llvm-project/issues/53904#issuecomment-1877114034. Not sure I fully understand the "we leave the external AST enabled so we can get called for contained types" idea. Happy to chat about how to make this work though https://github.com/llvm/llvm-project/pull/77029 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
