Add some large, fixed code bases alongside fuzzing

[atomb]

To determine how well the parser is working with different LLVM versions, we could build on the multi-version LLVM fuzzing workflow to also test against some fixed code bases that make use of various interesting language features. With the current testing infrastructure, that'll only identify parse failures, not semantic issues, but it's a step.

[langston-barrett]

Shameless plug: This tool has helped me get bitcode for large codebases: https://github.com/langston-barrett/nixpkgs-blight.

It doesn't produce whole-program bitcode (i.e. doesn't recursively compile library dependencies and link their bitcode), but that shouldn't matter if the goal is just to find parse failures.

[atomb]

Oh, cool! At the very least, blight would probably be useful. It might be more work to make the testing system use Nix than it would save us, although maybe not. And, yeah, I agree that we don't need combined bitcode for this purpose.

[travitch]

Another shameless bitcode generation plug https://github.com/travitch/build-bom

[langston-barrett]

It might be more work to make the testing system use Nix than it would save us, although maybe not.

Ah, I was thinking of having checked-in pre-compiled codebases but maybe that wasn't the intent here.

[atomb]

It might be more work to make the testing system use Nix than it would save us, although maybe not.

Ah, I was thinking of having checked-in pre-compiled codebases but maybe that wasn't the intent here.

Oh, yeah, that might actually be the better way to go. It'll make the tests faster and more reproducible.