[PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex

[PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex

[Alison Schofield]

While validating recent CXL ABI documentation updates with
get_abi.py, the 'undefined' mode was found to abort instead of
reporting undocumented ABI entries.

Older Python releases raise re.error, while newer releases expose
re.PatternError. Catching only the newer name causes the scan to
abort when an invalid expression is encountered.

Catch both names so the scan continues and reports the remaining
results.

Signed-off-by: Alison Schofield <alison.schofield@intel.com>
---
 tools/lib/python/abi/abi_regex.py | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/lib/python/abi/abi_regex.py b/tools/lib/python/abi/abi_regex.py
index d0c5e3ede6b5..69d8507b7382 100644
--- a/tools/lib/python/abi/abi_regex.py
+++ b/tools/lib/python/abi/abi_regex.py
@@ -155,7 +155,7 @@ class AbiRegex(AbiParser):
             if self.search_string:
                 if what.find(self.search_string) >= 0:
                     print(f"What: {what}")
-        except re.PatternError:
+        except re.error:
             self.log.warning("Ignoring '%s' as it produced an invalid regex:\n"
                              "           '%s'", what, new)
 
@@ -194,7 +194,7 @@ class AbiRegex(AbiParser):
 
                 try:
                     self.re_string = re.compile(self.search_string)
-                except re.PatternError as e:
+                except re.error as e:
                     msg = f"{self.search_string} is not a valid regular expression"
                     raise ValueError(msg) from e
 
@@ -223,9 +223,9 @@ class AbiRegex(AbiParser):
                 for r, s in self.re_whats:
                     try:
                         new = r.sub(s, new)
-                    except re.PatternError as e:
+                    except re.error as e:
                         # Help debugging troubles with new regexes
-                        raise re.PatternError(f"{e}\nwhile re.sub('{r.pattern}', {s}, str)") from e
+                        raise re.error(f"{e}\nwhile re.sub('{r.pattern}', {s}, str)") from e
 
                 v["regex"].append(new)
 

base-commit: 075b74841bd0065a3bda3440873c747938e69b68
-- 
2.37.3

[PATCH 2/2] docs: python: abi_regex: convert adjacent index placeholders

[Alison Schofield]

While validating recent CXL ABI documentation updates with
get_abi.py, every decoderX.Y entry was reported as undocumented.

The placeholder conversion mishandles adjacent index placeholders,
producing patterns that cannot match the corresponding sysfs paths.
As a result, valid ABI entries are reported as undocumented.

Handle adjacent placeholders independently so generated patterns match
the documented paths. This fixes decoderX.Y entries in the CXL ABI and
other ABI documentation that uses the same naming convention.

Signed-off-by: Alison Schofield <alison.schofield@intel.com>
---
 tools/lib/python/abi/abi_regex.py | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/lib/python/abi/abi_regex.py b/tools/lib/python/abi/abi_regex.py
index 69d8507b7382..198ecbf49c51 100644
--- a/tools/lib/python/abi/abi_regex.py
+++ b/tools/lib/python/abi/abi_regex.py
@@ -65,8 +65,7 @@ class AbiRegex(AbiParser):
         (re.compile(r"\[[^\]]+\]"), "\\\\w\xf7"),
 
         (re.compile(r"XX+"), "\\\\w\xf7"),
-        (re.compile(r"([^A-Z])[XYZ]([^A-Z])"), "\\1\\\\w\xf7\\2"),
-        (re.compile(r"([^A-Z])[XYZ]$"), "\\1\\\\w\xf7"),
+        (re.compile(r"(?<![A-Z])[XYZ](?![A-Z])"), "\\\\w\xf7"),
         (re.compile(r"_[AB]_"), "_\\\\w\xf7_"),
 
         # Recover [0-9] type of patterns
-- 
2.37.3

Re: [PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex

[Alison Schofield]

On Fri, Aug 07, 2026 at 12:03:44AM +0000, sashiko-bot@kernel.org wrote:
> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
> - [Medium] The patch replaces `re.PatternError` with `re.error` rather than catching both, directly contradicting the commit message and exposing a misunderstanding of standard Python.

It does indeed catch both by simply using 're.error'.

re.PatternError is not a separate exception because re.error was
kept as an alias for backward compatibility.

So yes, a bit of secret sauce not obvious in the commit message.

I'll wait a bit and see if Maintainers want a respin with a commit
log update for that.


> --
> 
> --- Patch [1]: [PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex ---
> commit ed601931671f151d8ef4f1bbd0e817520a34f3c5
> Author: Alison Schofield <alison.schofield@intel.com>
> 
> docs: python: abi_regex: catch the right exception for a bad regex
> 
> This commit updates the exception handling in abi_regex.py to prevent the
> script from aborting on invalid regular expressions. It aims to support
> both older and newer Python releases by handling regex errors correctly.
> 
> > Older Python releases raise re.error, while newer releases expose
> > re.PatternError. Catching only the newer name causes the scan to
> > abort when an invalid expression is encountered.
> > 
> > Catch both names so the scan continues and reports the remaining
> > results.
> 
> [Severity: Medium]
> Does the commit message accurately reflect the changes? 
> 
> The text states it will "Catch both names", but the patch replaces 
> re.PatternError with re.error entirely. While standard Python uses re.error, 
> if newer releases actually exposed re.PatternError as stated in the commit 
> message, wouldn't replacing the handler cause newer Python releases to abort?
> 
> > diff --git a/tools/lib/python/abi/abi_regex.py b/tools/lib/python/abi/abi_regex.py
> > --- a/tools/lib/python/abi/abi_regex.py
> > +++ b/tools/lib/python/abi/abi_regex.py
> > @@ -155,7 +155,7 @@ class AbiRegex(AbiParser):
> >              if self.search_string:
> >                  if what.find(self.search_string) >= 0:
> >                      print(f"What: {what}")
> > -        except re.PatternError:
> > +        except re.error:
> 
> [Severity: Medium]
> Is it intentional to only catch re.error here in regex_append(), rather
> than catching both as described in the commit message?
> 
> [ ... ]
> 
> > @@ -194,7 +194,7 @@ class AbiRegex(AbiParser):
> >  
> >                  try:
> >                      self.re_string = re.compile(self.search_string)
> > -                except re.PatternError as e:
> > +                except re.error as e:
> 
> [Severity: Medium]
> Does this __init__() block also need to catch both exceptions, or is
> replacing re.PatternError with re.error sufficient?
> 
> [ ... ]
> 
> > @@ -223,9 +223,9 @@ class AbiRegex(AbiParser):
> >                  for r, s in self.re_whats:
> >                      try:
> >                          new = r.sub(s, new)
> > -                    except re.PatternError as e:
> > +                    except re.error as e:
> >                          # Help debugging troubles with new regexes
> > -                        raise re.PatternError(f"{e}\nwhile re.sub('{r.pattern}', {s}, str)") from e
> > +                        raise re.error(f"{e}\nwhile re.sub('{r.pattern}', {s}, str)") from e
> 
> [Severity: Medium]
> Similar to the other locations, parse_abi() replaces the exception class
> instead of catching both. Does this match the intended behavior?
> 
> -- 
> Sashiko AI review · https://sashiko.dev/#/patchset/d57d3ddc0d7d883bd61ad07c6d3969b622fd446f.1786058698.git.alison.schofield@intel.com?part=1

Re: [PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex

[Jonathan Corbet]

Alison Schofield <alison.schofield@intel.com> writes:

> On Fri, Aug 07, 2026 at 12:03:44AM +0000, sashiko-bot@kernel.org wrote:
>> Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
>> - [Medium] The patch replaces `re.PatternError` with `re.error` rather than catching both, directly contradicting the commit message and exposing a misunderstanding of standard Python.
>
> It does indeed catch both by simply using 're.error'.
>
> re.PatternError is not a separate exception because re.error was
> kept as an alias for backward compatibility.
>
> So yes, a bit of secret sauce not obvious in the commit message.
>
> I'll wait a bit and see if Maintainers want a respin with a commit
> log update for that.

[Almost missed this - said maintainers respond more reliably when copied
on the emails].

Explaining that you're catching the superclass error would have been
better, certainly.  Respin if you like but, in this case, I'm not sure
it's worth the trouble.

Thanks,

jon