This avoids unintentional comparisons between `SourceLanguage` and `LanguageType`. Also marks `operator bool` explicit so we don't implicitly convert to bool.
### Summary This PR refactors breakpoint event notification in LLDB to centralize and eliminate code duplication. It creates a unified method in the `Target` class for sending breakpoint change events. The new methods check if listeners exist before broadcasting events ### Test <img width="1532" height="76" alt="Screenshot 2025-10-23 at 12 49 31 PM" src="https://github.com/user-attachments/assets/6d6a6da6-9684-463c-aeeb-90663cdbd077" /> --------- Co-authored-by: Piyush Jaiswal <piyushjais@meta.com>
This patch adds the notion of "Facade" locations which can be reported from a ScriptedResolver instead of the actual underlying breakpoint location for the breakpoint. Also add a "was_hit" method to the scripted resolver that allows the breakpoint to say which of these "Facade" locations was hit, and "get_location_description" to provide a description for the facade locations. I apologize in advance for the size of the patch. Almost all of what's here was necessary to (a) make the feature testable and (b) not break any of the current behavior. The motivation for this feature is given in the "Providing Facade Locations" section that I added to the python-reference.rst so I won't repeat it here. rdar://152112327
LLDB breakpoint conditions take an expression that's evaluated using the language of the code where the breakpoint is located. Users have asked to have an option to tell it to evaluate the expression in a specific language. This is feature is especially helpful for Swift, for example for a condition based on the value in memory at an offset from a register. Such a condition is pretty difficult to write in Swift, but easy in C. This PR adds a new argument (-Y) to specify the language of the condition expression. We can't reuse the current -L option, since you might want to break on only Swift symbols, but run a C expression there as per the example above. rdar://146119507
This RP changes some Breakpoint-related interfaces to return errors. On its own these improvements are small, but they encourage better error handling going forward. There are a bunch of other candidates, but these were the functions that I touched while working on #146602.
This adds SBBreakpoint::SetIsHardware, allowing clients to mark an existing breakpoint as a hardware breakpoint purely through the API. This is safe to do after creation, as the hardware/software distinction doesn't affect how breakpoint locations are selected. In some cases (e.g. when writing a trap instruction would alter program behavior), it's important to use hardware breakpoints. Ideally, we’d extend the various `Create` methods to support this, but given their number, this patch limits the scope to the post-creation API. As a workaround, users can also rely on target.require-hardware-breakpoint or use the `breakpoint set` command. rdar://153528045
The LLVM Coding Standards [1] discourages the use of 'else' or 'else if' after something that interrupts control flow. Bulk fix all instances as I'm working on this part of LLDB. [1] https://llvm.org/docs/CodingStandards.html#don-t-use-else-after-a-return
This fixes the two test suite failures that I missed in the PR: https://github.com/llvm/llvm-project/pull/112939 One was a poorly written test case - it assumed that on connect to a gdb-remote with a running process, lldb MUST have fetched all the frame 0 registers. In fact, there's no need for it to do so (as the CallSite patch showed...) and if we don't need to we shouldn't. So I fixed the test to only expect a `g` packet AFTER calling read_registers. The other was a place where some code had used 0 when it meant LLDB_INVALID_LINE_NUMBER, which I had fixed but missed one place where it was still compared to 0.
…ne stepping (#112939)" This was breaking some gdb-remote packet counting tests on the bots. I can't see how this patch could cause that breakage, but I'm reverting to figure that out. This reverts commit f14743794587db102c6d1b20f9c87a1ac20decfd.