chore: move to Stephen's submodules

[difcsi]

No description provided.

[difcsi]

I am a bit puzzled by this build passing: if the submodule remote is Stephen's repository, how is it able to pull the commits pinned?

[stephenrkell]

It may be that my repos have the hashes somewhere in them? That does seem unlikely. I have a hazy memory that the .gitmodules file is not the final word on where submodules come from, but I could be wrong.

Note that I pushed to toolsub over the weekend. I made a version that is a minimal diff from classic CIL and in fact can build against either. You might want to update this PR to point at that toolsub.

(Doing that was mostly as an exercise for me to understand what's changed. However, I see value in being able to build against either CIL for now, e.g. if we find some regression that we want to bisect or otherwise explore. I plan to update the liballocs OCaml build rules to repeat the same pattern and allow building against goblint or classic CIL. Though, we don't need to do that prior to switching back to my CIL.)

[jryans]

I am a bit puzzled by this build passing: if the submodule remote is Stephen's repository, how is it able to pull the commits pinned?

GitHub is known to store all forks of a repo together in one bucket behind the scenes, which is part of why you can e.g. view a commit URL that names the upstream repo together with a commit hash that is not part of that upstream repo, for example:

stephenrkell/toolsub@0aa9d07

It may be that this GitHub storage choice also impacts the packs sent to local Git clones, such that cloning the upstream also includes pushed commits of forks as well.

[difcsi]

You might want to update this PR to point at that toolsub.

I'd leave that to @dependabot, it will follow this PR up with a submodule PR bump once it knows where to look for the submodule.

#195 makes me think it follows .gitmodules as it is pulling from Peter's fork

GitHub is known to store all forks of a repo together in one bucket behind the scenes

Oh, I didn't know this. But it does explain what we are seeing here. Thanks for the info!

It may be that this GitHub storage choice also impacts the packs sent to local Git clones, such that cloning the upstream also includes pushed commits of forks as well.

This surely isn't safe: one could add a large binary to a fork and generate thousands of commits of renaming it. If git pulls those too, it would be possible to seriously degrade upstream repo performance by fork-spamming

[stephenrkell]

OK. Hmm. So if I merge this, it will break the build until I make some consequent fixes. I think these are not simply "do as dependabot suggests"... I need to point it at a non-head commit of my toolsub (pending liballocs changes to the contrib build) and the relevant branch of my cil.

I can do this just now, hopefully... though can't promise I won't revert for now if it doesn't go smoothly.

[stephenrkell]

The current test failures (everything fails) reflect that my goblint CIL fork chokes on #define lines left behind from preprocessing with -g3 or (as implied by the latter) -Wp,-dD.

That tells me @mbyzhang's CIL fork has some commits that we need and that my branch does not yet have.... indeed I remember we worked on the -Wp,-dD support as part of the nomachdep stuff. I'll take a look at this tomorrow.

[mbyzhang]

Yes, I actually opened a PR (stephenrkell/cil#23) that reverts your nomachdep commits, on which my migrate-to-goblint liballocs PR depends.

[stephenrkell]

Thanks @mbyzhang. I've now (apologies for the delay!) merged that PR.