I’m trying to find out where clang finds deprecated compiler-generated special member functions so I can update a clang tidy check I am working on to apply the same logic.
I’m not sure where to start looking. I have some simple test code that triggers the warning I want but asking LLDB to stop at program entry when debugging clang won’t print out source. I can explicitly print out source lines but it won’t show me which line I’m at. This renders exploration impossiblel, I fear there’s a trick I’m missing.
I’ve tried searching code for diagnostic text but this seems to happen a fair way away from diagnosing the issue.
I can’t give you concrete answer but here’s a hint or two that might help.
When debugging, are you passing -cc1 to the process. If not you’re invoking the driver and it never executes Sema code, it starts a new process to get actual compilation done.
I guess you know about diagnostic text being inside .td files. Sometimes it’s hard to find the identifier for a specific diagnostic because the text in .td file is not identical to diagnostic that’s emitted. I put a breakpoint in DiagnosticBuilder::Emit whenever I have trouble finding the exact place where diagnostic is being emitted from.
I’d be very surprised if the logic for detecting this issue is far from code that emits the diagnostic. Just follow the condition.