bug#58672: 29.0.50; [noverlay] overlays-in returns overlays for empty range

[Matt Armstrong]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Fix was pretty simple.  We iterate with an END range of ZV or ZV+1, then
>> bail when node->beg gets past the 'end' we really care about.  The code
>> was returning all nodes beginning at 'end', when it should have been
>> skipping past the non-empty ones.
>>
>> It is attached and in the my/bug58672 branch at
>> https://git.sr.ht/~matta/emacs/log/my/bug58672 in my
>> https://git.sr.ht/~matta/emacs repo.
>
> Thanks, merged.
>
> [ I'm still trying to track down the origin of bug: the new code should
>   not just reproduce the behavior of the old one, but it should also
>   preserve as much of the old code as possible to avoid introducing such
>   bugs.  ]

I've just found places where the old code had special treatment for edge
cases that weren't handled by the new 'overlays_in'.

In particular, the edge cases are:

a) Returning empty overlays, or not.

b) Returning all overlays that *begin* at ZV iff the END passed to
'overlays_in' is == ZV.

c) Returning the empty overlays that *begin* at ZV iff the END passed to
'overlays_in' is == ZV.

d) Special casing retrieval based on the overlay's
front-advance/rear-advance at a particular POS.

The BEGIN arg to 'overlays_in' is the disjunction of (a) and (b).  In
another patch I added TRAILING arg that is (b).  Yet another patch could
have used (d) had 'overlays_in' supported it, but instead I post-process
the resulting vector.

Perhaps 'overlays_in' should instead take a filter predicate instead of
a bunch of options.