Increment parser timestamp when narrowing changes (bug#67977)

When narrowing changes, parse reparses, so the timestamp should
definitely increment, just like in ts_record_changes.

Failing to increment this timestamp, outdated nodes would think they
are still up-to-date, and try to print their type name.  Printing
their type name involves accessing the old parse tree, which is
already freed during the last reparse.

I also found that we don't increment timestamp when changing parser
ranges and fixed that as well.

* src/treesit.c (treesit_sync_visible_region):
(Ftreesit_parser_set_included_ranges): Increment timestamp.
* src/treesit.h (Lisp_TS_Parser): Add some comments.

src/treesit.c

@@ -931,7 +931,10 @@ treesit_sync_visible_region (Lisp_Object parser)
      this function is called), we need to reparse.  */
   if (visible_beg != BUF_BEGV_BYTE (buffer)
       || visible_end != BUF_ZV_BYTE (buffer))
-    XTS_PARSER (parser)->need_reparse = true;
+    {
+      XTS_PARSER (parser)->need_reparse = true;
+      XTS_PARSER (parser)->timestamp++;
+    }
 
   /* Before we parse or set ranges, catch up with the narrowing
      situation.  We change visible_beg and visible_end to match
@@ -1671,6 +1674,7 @@ buffer.  */)
 	      ranges);
 
   XTS_PARSER (parser)->need_reparse = true;
+  XTS_PARSER (parser)->timestamp++;
   return Qnil;
 }
 

src/treesit.h

@@ -53,7 +53,9 @@ struct Lisp_TS_Parser
   /* Re-parsing an unchanged buffer is not free for tree-sitter, so we
      only make it re-parse when need_reparse == true.  That usually
      means some change is made in the buffer.  But others could set
-     this field to true to force tree-sitter to re-parse.  */
+     this field to true to force tree-sitter to re-parse.  When you
+     set this to true, you should _always_ also increment
+     timestamp.  */
   bool need_reparse;
   /* These two positions record the buffer byte position (1-based) of
      the "visible region" that tree-sitter sees.  Before re-parse, we