$ git log --pretty=format:'%h %s (%cs)%d'
60a1ee96 substitute(): convert switch() into cascade of ifs (2026-03-16)
(HEAD -> master)
2ce7767d make expand_one_symbol() inline (2026-03-16)
c4379915 simplify the calling conventions of collect_arguments() (2026-03-16)
4dae3e04 merge(): saner handling of ->noexpand (2026-03-16)
ae58ca73 expansion-time va_opt handling (2026-03-16)
1a9a98e3 __VA_OPT__: parsing (2026-03-16)
95629d52 pre-process.c: split try_arg() (2026-03-16)
8a7fbca4 preparations for __VA_OPT__ support: reshuffle argument slot assignments (2026-03-16)
be4532e5 deal with ## on arguments separately (2026-03-16)
a5dadf62 stop mangling arglist, get rid of TOKEN_ARG_COUNT (2026-03-16)
...
$ git cat-file blob HEAD:README
sparse (spärs), adj,., spars-er, spars-est.
1. thinly scattered or distributed; "a sparse population"
2. thin; not thick or dense: "sparse hair"
3. scanty; meager.
4. semantic parse
[ from Latin: spars(us) scattered, past participle of
spargere 'to sparge' ]
Antonym: abundant
Sparse is a semantic parser of source files: it's neither a compiler
(although it could be used as a front-end for one) nor is it a
preprocessor (although it contains as a part of it a preprocessing
phase).
It is meant to be a small - and simple - library. Scanty and meager,
and partly because of that easy to use. It has one mission in life:
create a semantic parse tree for some arbitrary user for further
analysis. It's not a tokenizer, nor is it some generic context-free
parser. In fact, context (semantics) is what it's all about - figuring
out not just what the grouping of tokens are, but what the _types_ are
that the grouping implies.
And no, it doesn't use lex and yacc (or flex and bison). In my personal
opinion, the result of using lex/yacc tends to end up just having to
fight the assumptions the tools make.
The parsing is done in five phases:
- full-file tokenization
- pre-processing (which can cause another tokenization phase of another
file)
- semantic parsing.
- lazy type evaluation
- inline function expansion and tree simplification
Note the "full file" part. Partly for efficiency, but mostly for ease of
use, there are no "partial results". The library completely parses one
whole source file, and builds up the _complete_ parse tree in memory.
Also note the "lazy" in the type evaluation. The semantic parsing
itself will know which symbols are typedefines (required for parsing C
correctly), but it will not have calculated what the details of the
different types are. That will be done only on demand, as the back-end
requires the information.
This means that a user of the library will literally just need to do
struct string_list *filelist = NULL;
char *file;
action(sparse_initialize(argc, argv, filelist));
FOR_EACH_PTR(filelist, file) {
action(sparse(file));
} END_FOR_EACH_PTR(file);
and he is now done - having a full C parse of the file he opened. The
library doesn't need any more setup, and once done does not impose any
more requirements. The user is free to do whatever he wants with the
parse tree that got built up, and needs not worry about the library ever
again. There is no extra state, there are no parser callbacks, there is
only the parse tree that is described by the header files. The action
funtion takes a pointer to a symbol_list and does whatever it likes with it.
The library also contains (as an example user) a few clients that do the
preprocessing, parsing and type evaluation and just print out the
results. These clients were done to verify and debug the library, and
also as trivial examples of what you can do with the parse tree once it
is formed, so that users can see how the tree is organized.
# heads (aka `branches'):
$ git for-each-ref --sort=-creatordate refs/heads \
--format='%(HEAD) %(refname:short) %(subject) (%(creatordate:short))'
* master substitute(): convert switch() into cascade of ifs (2026-03-16)
fix-zephyr reassoc: fix infinite loop during reassociation (2023-12-28)
handle-cleanup-attr parse: handle __cleanup__ attribute (2023-12-16)
bitwise-ones bitwise: early expansion of simple constants (2022-06-27)
# tags:
$ git for-each-ref --sort=-creatordate refs/tags \
--format='%(refname:short) %(subject) (%(creatordate:short))'
v0.6.4 v0.6.4 (2021-09-06) tar.gz
v0.6.4-rc1 v0.6.4-rc1 (2021-09-01) tar.gz
v0.6.3 v0.6.3 (2020-10-18) tar.gz
v0.6.3-rc1 v0.6.3-rc1 (2020-10-12) tar.gz
v0.6.2 v0.6.2 (2020-06-21) tar.gz
v0.6.2-rc2 v0.6.2-rc2 (2020-06-18) tar.gz
v0.6.2-rc1 v0.6.2-rc1 (2020-06-13) tar.gz
v0.6.1 v0.6.1 (2019-10-14) tar.gz
v0.6.1-rc1 v0.6.1-rc1 (2019-03-01) tar.gz
v0.6.0 v0.6.0 (2018-12-26) tar.gz
...
# associated public inboxes:
# (number on the left is used for dev purposes)
2861 linux-sparse
129 lkml
20 qemu-devel
20 linux-arm-kernel
19 u-boot
18 netdev
15 linux-devicetree
14 stable
14 buildroot
12 git
11 intel-gfx
10 linux-riscv
10 dpdk-dev
9 linux-fsdevel
8 dri-devel
8 smatch
7 linux-wireless
7 linux-media
7 linuxppc-dev
7 kvm
7 amd-gfx
6 linux-samsung-soc
6 linux-acpi
6 linux-mm
6 linux-mmc
6 linux-api
6 ltp
5 linux-mtd
5 linux-block
5 linux-xfs
5 netfilter-devel
5 linux-arm-msm
5 xen-devel
5 alsa-devel
5 linux-scsi
5 linux-clk
5 linux-pci
5 linux-bluetooth
5 linux-omap
5 openembedded-core
5 openembedded-devel
4 bpf
4 linux-nfs
4 linux-mediatek
4 linux-crypto
4 linux-cifs
4 linux-amlogic
4 linux-btrfs
4 kvmarm
4 linux-iio
4 linux-rdma
4 linux-security-module
4 linux-f2fs-devel
4 linux-ide
4 virtualization
4 linux-s390
4 lvm-devel
3 linux-nvme
3 linux-efi
3 linux-erofs
3 linux-iommu
3 linux-mips
3 fstests
3 linux-pm
3 linux-input
3 driverdev-devel
3 linux-usb
3 linux-kselftest
3 linux-ext4
3 linux-watchdog
3 util-linux
3 linux-doc
3 linux-man
3 linux-spi
3 linux-tegra
3 linux-kbuild
3 ceph-devel
3 linux-raid
3 openbmc
3 linux-fbdev
3 linux-perf-users
3 linux-sh
3 ocfs2-devel
3 nouveau
3 yocto-meta-virtualization
3 kexec
3 intel-xe
3 poky
3 cluster-devel
3 reiserfs-devel
2 linux-integrity
2 linux-nvdimm
2 linux-rtc
2 linux-renesas-soc
2 selinux
2 kernel-hardening
2 linux-gpio
2 linux-modules
2 linux-rt-users
2 linux-serial
2 linux-trace-devel
2 linux-hyperv
2 backports
2 linux-audit
2 linux-i2c
2 mm-commits
2 lttng-dev
2 linux-arch
2 linux-can
2 containers
2 linux-rockchip
2 linux-hardening
2 dm-devel
2 linux-cxl
2 target-devel
2 linux-phy
2 kernel-janitors
2 linux-staging
2 linux-sunxi
2 linux-coco
2 nvdimm
2 iwd
2 yocto
2 yocto-meta-freescale
2 yocto-toaster
2 yocto-meta-arm
2 bitbake-devel
2 yocto-meta-ti
2 yocto-meta-arago
2 outreachy
2 xenomai
2 openrisc
2 intel-wired-lan
2 batman
2 linux-um
2 virtio-dev
2 virtio-comment
2 qemu-riscv
2 grub-devel
2 cgroups
2 initramfs
2 kvm-ppc
2 linux-hexagon
2 virtio-fs
2 fuego
2 igt-dev
1 linux-fscrypt
1 cocci
1 live-patching
1 linux-edac
1 linux-snps-arc
1 linux-hwmon
1 dmaengine
1 linux-next
1 linux-parisc
1 linux-leds
1 kernelnewbies
1 linux-sgx
1 workflows
1 rcu
1 selinux-refpolicy
1 linux-m68k
1 linux-i3c
1 linux-spdx
1 linux-wpan
1 ksummit-discuss
1 wireguard
1 io-uring
1 linux-kernel-mentees
1 linux-csky
1 tpmdd-devel
1 linux-unionfs
1 linux-firmware
1 cip-dev
1 linux-remoteproc
1 linux-dash
1 linux-bcache
1 linux-pwm
1 linux-fpga
1 xdp-newbies
1 platform-driver-x86
1 phone-devel
1 dash
1 keyrings
1 linux-sctp
1 lustre-devel
1 soc
1 rust-for-linux
1 ath10k
1 ath11k
1 sparclinux
1 mptcp
1 regressions
1 ksummit
1 b43-dev
1 linux-nfc
1 linux-bcachefs
1 ath9k-devel
1 ntfs3
1 llvm
1 fio
1 ell
1 ofono
1 yocto-docs
1 linux-patches
1 chrome-platform
1 ntb
1 damon
1 asahi
1 loongarch
1 imx
1 ath12k
1 b4-sent
1 linux-trace-kernel
1 oe-linux-nfc
1 oe-kbuild-all
1 oe-chipsec
1 v9fs
1 ecryptfs
1 linux-ia64
1 kbd
1 autofs
1 cpufreq
1 dccp
1 devicetree-spec
1 devicetree-compiler
1 hail-devel
1 kvm-ia64
1 linux-8086
1 kernel-testers
1 linux-alpha
1 linux-btrace
1 linux-embedded
1 linux-hams
1 linux-hotplug
1 linux-laptop
1 linux-sound
1 trinity
1 linux-metag
1 linux-x25
1 linux-nilfs
1 lvs-devel
1 netfilter
1 linux-oxnas
1 u-boot-amlogic
1 lm-sensors
1 acpica-devel
1 perfbook
1 wireless-regdb
1 powertop
git clone https://yhbt.net/lore/pub/scm/devel/sparse/sparse-dev.git