bug#58780: python.el infinite loop in info-current-defun

[JD Smith <jdtsmith@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2218 bytes --]

I noticed python.el hangs hard on some of my files when `python-info-current-defun` is set up for use with which-function, and I open (but haven’t yet closed) a triple string: “”".  I tracked this down to a bug in `python-nav-end-of-statement` when an unclosed string is included in a file:

==========
def try():
    """Do the Foo

def a():
    """Do A's stuff"""
    a = True

===========

(Note: the final newline is important).  (python-info-current-defun) hangs on the unclosed docsig string of try().  

The reason why can be demonstrated by placing the cursor before a = True on the final line and (python-nav-end-of-statement).  Point moves to the end of the previous line!   Since `python-nav-end-of-defun` calls end-of-statement repeatedly looking for (eobp), this results in an infinite loop.  The problem is this call in end-of-statement:

  (re-search-forward (rx (syntax string-delimiter)) nil t)

Search starts at the single apostrophe in Do A’s stuff (the beginning of the apparent-but-incorrect string ppss has found), then searches forward to the triple quote at the end of the (prior) line.  

To reproduce this you need:

- an unclosed triple string above
- a triple string with another type of quote mark enclosed
- something after the final “”” (to prevent eobp). 

These are surprisingly common conditions to encounter given python docstring format.  A fix might be to insist that the `python-nav-end-of-statement` occurs at least at the end of the current line, or perhaps to improve the regex search for the end of string to match the opening string delimiter (although this could also be fooled I think).

This is Emacs 28, though aside from some additional commentary about such issues, end-of-statement hasn’t changed in the latest. 

As an aside, having stepped through this code, it seems python’s structural navigation and inspection are _very_ heavy, commonly traversing entire files one statement at a time to find the local function name, for example.  Due to their complexity, they are also susceptible to these types of infinite loops when syntax is in a temporarily broken state.  Good arguments for the inclusion of tree-sitter!


[-- Attachment #2: Type: text/html, Size: 4579 bytes --]