cpplint

Very inefficient work today again, partly because it turned out something I did last time didn’t commit. Another 20 minutes of interface things later, I somehow still feel very powerful. JetBrains IDEs are magic.
Since last time, we’ve got two new candidate maintainers popping in to review changes (using suspiciously LLM-sounding language, still …), and thus it’s natural that I increase my work by two as well. I followed up on two more pull requests.
⁂

The first one was somewhat simple. There’s a zsh script I put into the root of the project to detect changes in the tests against real-life sample code, and it turns out the trap I added to clean up temp files after early termination forgot to terminate the code. I wasted unlogged time shell-reading the zsh manual, which advertised an extremely outdated and incomplete online version, until I realized there was in fact a current and complete online manual. 🥀
In summary, zsh trap functions replace the single slot of the function to execute upon the kill signal. That’s very elegant, actually. I initially added the trap code upon suggestion from Coderabbit AI pull-request review and this devious devilous leporine tried to make it so we could never kill the machines. I’m scared. /j
⁂

The second one actually took quite a bit of thought. cpplint has a feature to warn on C-style casts to suggest more specific C++ casts instead. The PR was to make it stop detecting function pointers that take a pointer argument as casts if they happened to be marked noexcept. My original solution added an exception to noexcepts, which a candidate maintainer reviewer found was overly broad and suppressing casts of the bool value of the noexcept operator. Which, though niche, actually does seem plausible.
I drew up two different solutions, and decided to ask the JetBrains powered LLM-with-no-name which one was better. It correctly identified that the optional group could simply not be matched and is probably less optimized than the identical lookbehind, but then kept insisting function p. So I put it to death.
I proclaimed my own lookbehind creation, for only man can make divine. After a hiccup involving my misunderstanding of the difference between lookbehinds and lookaheads (Dear Past Me: duh), I settled for detecting an unspaced closing parenthesis because non–function pointer cases of such syntax would surely be formatted with a space by sane minds. coderabbit AI, which notably lacks a mind, agreed.

Even if it’s all machine, the project (tracker) finally seems alive.

Wow, it’s been a long time since I’ve worked on this. I had to spend a lot of time re-learning my PyCharm workflows. I had to solve some interesting font issues with my IDEs and relearn PyCharm’s great Git interface. (Seriously, why is the push button not in the UI if you don’t have a commit to commit?)

I got a tip from another candidate maintainer that my previous refactoring broke support for Pytest 8, so now we require Pytest 9.
Then it turned out PyCharm failed to detect coverage because uv couldn’t resolve dependencies because Pytest 9 dropped support for Python 3.9, which we listed as supported, so now we require Python 3.10.
I am … not sure how to feel, as Pytest isn’t required to run the package! I’m probably going to write union types as X | Y and add some case statements to justify this bump.

We might finally get a new maintainer to actually review my code! I fear that he’s using AI to write sentences, though… I really hope his code isn’t AI.
At least it seems that it isn’t, because he’s overcomplicating things. He correctly pointed out that the form LLU instead of ULL is also often used as a literal suffix (that we would need to detect) and that the insensitivity should be an inline group instead of flag, but then came up with this monstrosity: (?i:(?:U(?:LL?)?|(?:LL?)U?)?). I confirmed that the more orthodox (?i:U|UL|ULL|L|LL|LU|LLU) was faster (and readable!), that (?i) is a real thing (wow! thanks pythoma), ran tests, and committed the changes straight from GitHub after spending way too much time figuring out how the PR tab in PyCharm worked. An overcomplication to end an exploration of overcomplications.