reafactor(variables): Add variable registry

[Caellian]

This is a large refactor that untangles most of the code from core.cc. It removes the huge if-elseif-elseif chain in core.cc and replaces it with a registry pattern and std::unordered_map lookup.

Improvements:

• Removes a lot of headers that were exporting only printing functions previously.
• Opens up possibility of automating documentation coverage.
• Simplifies variable aliases ([Bug]: Inconsistency of spelling in variable own_window_colour #2240 cleaner).
• Allows dynamic insertion of variables (a must for [Feature]: support variable definitions in Lua #2310).
• Speeds up compilation because core.cc no longer needs blocks on everything else.
• Variables are declared next to related code. 100x more readable.
• Parsing variables is O(1) amortized, instead of O(n). (Though this wasn't really a huge cost)

Changes that affect functionality (fix bugs) are separated into their own commits so they can be reverted separately if needed; none of refactor commits affect behavior.

This PR requires bumping GCC minimal supported version to 13 (expand for details)

---

GCC 13.1 was released: April 26, 2023

GCC 13.1 is needed because a macro added in variables.hh relies on P1907R1 ("Inconsistencies with non-type template parameters") being applied as a defect resolution to C++17 mode. The print_variable macro bridges C++17 lambdas into NTTP function pointers via a local struct's static member, whose address has no linkage under too-broad C++17 [basic.link]/8 rule. GCC 13+ and Clang treat P1907R1 as a DR and accept this in C++17 mode; GCC 11/12 do not. In C++20 this workaround becomes unnecessary because stateless lambdas are valid NTTPs directly.

Intuitively, this makes sense to be a DR because a non-capturing lambda is fully static, and a struct declared in it should be statically linkable too.

Not having P1907R1 means that we can't use non-capturing lambdas for variable parsing, which avoidable but ugly because it reverts to having ~100 functions that are 1-3 lines of "read and print variable" code. DR makes this much cleaner.

Ubuntu 24.04 does have GCC 13/14, so this change doesn't affect compatibility matrix for official distro packaging (buildd), 22.04 will only backport security vulnerabilities.

GCC issue: gcc#96645

---

Closes #2052.

This is WIP until I move all variable parsing out of core.cc. But each commit compiles and runs in isolation and can be tested as-is.

[netlify]

✅ Deploy Preview for conkyweb canceled.

Name	Link
🔨 Latest commit	2e79529
🔍 Latest deploy log	https://app.netlify.com/projects/conkyweb/deploys/69f2d2e0dd6e640007ffcdc6

[brndnmtthws]

@npyl just pushed some crypto spam to this branch. I am working on reverting that, and have blocked & reported the account (I'm guessing their credentials were compromised).

[brndnmtthws]

As a heads-up: I am going to change the branch policy to disallow force pushes to any branch (not just main), just in case anyone with collaborator access gets compromised again.

[Caellian]

As a heads-up: I am going to change the branch policy to disallow force pushes to any branch (not just main), just in case anyone with collaborator access gets compromised again.

@brndnmtthws That breaks rebasing, makes PRs extremely annoying to use, and doesn't really improve security.

Without force-pushes, PR branches effectively become append-only:

• rebasing onto updated main is impossible
• fixup commits and squash are broken on working branches
• long-running branches accumulate merge commits or stale history
  • reviewers can't review commit diff anymore because - you're forcing them to review the final diff because it's the only non-noisy one
  • these PRs now must be squash merged, even if parts of them were reversible before
    • disables revert commits for larger changes (e.g. refactor + one tiny change)

A collaborator with previous contribution can just push a new commit on top of someone else's PR, approve and merge the branch. Someone with alt accounts that both contributed can also still make a PR and verify it on their own.

The only solution is to limit approvals, and make them auto-retract when branch is mutated. At the moment, 185 accounts (besides yours) have mutable access to main, if there's an alt account among those, a single person can push malicious code to main on their own, regardless of branch/PR mutability.

Signing commits with GPG is what's supposed to address this problem, but that introduces friction for new developers.

What I suggest you do instead:

• auto-retract approvals on PR branch change,
• an additional tier of trust,
  • limit approvals to lasers, bi4k8, su8. g0mba, mmuman, ..., me
  • manage membership via a CI cron job: something like gh pr list --repo brndnmtthws/conky --state merged --limit 1000 --json author --jq '[.[].author.login] | group_by(.) | map({author: .[0], count: length}) | sort_by(-.count)', but time-amortized.

With that in place, you don't disable majority of git functionality and it solves the problem you're pointing to without the solution being a nuisance or enforcing bad practices GitHub already makes all too easy.

[brndnmtthws]

The main issue here was that someone rewrote the git history, which is annoying but not the worst thing. Let me think a bit more about it, I don't want to add too much friction and disabling force pushes just means you need to use merges instead of rebasing in your branch, but the final merge into master is always a rebase. I'll remove the rule for now but I might change my mind. I don't love the idea of requiring signed commits because most people don't sign their commits properly and invalidating approvals can be annoying when you want to approve the PR even if there are still some more follow-up changes needed. There's a balance here between avoiding bad things (such as likely credential compromise in this case) by making sure history can't be rewritten and making it super inconvenient for people.

[Caellian]

Ok, thank you for staying ahead of this. In this instance, my PRs were safe because I don't really ever pull from PR branches so their changes would've been overwritten once I rebased my local worktrees.

I don't merge using GitHub Web UI because it's incapable of preserving even commits that are directly on main.

I see it could be an issue for other contributors though and something that could erode trust towards people who are trying to enter the project.

Not promising anything, but I might make a PR for the proposed solution, and rethink approval retraction (maybe make it conditional and trigger under certain circumstances (a new account appearing in commits)). GH triggers CI events even on force pushes (commit overwrites), so that shouldn't be much of an issue.