C Programming – Moral Reasons to Avoid Static Linking

In general, you create A and add it to the scope. When you get to resolve B, you go and build B. When that gets to resolving A, it finds a (partially) constructed type and grabs that reference. Then you return back to building A.

There are other situations that are more problematic (like cyclical inheritence, dll references, recursive type declarations) that often require placeholder types or are simply not viable given other design constraints. In general, keeping each compilation phase thin helps prevent issues. For example, you can only do the partial type trick if nothing needs to know the members of A in B.

In practice, however, nothing works quite as well as expected, and the project has been on DEFCON 1 for half a year. Now, most of my peers are happy if they can go back home at 6pm - on Sunday.

This is certainly a good chunk of your problem. A software engineer cannot work productively for more than 40hours/week. If you go above that, you do serious damage to your capacity to work- to the point at which even working 80 hours/week brings very little of value to the project, and sometimes, projects can even regress because the team introduces more errors than they can fix. If you've been doing 60 hours/week or more for half a year, then your whole team needs a good long break, and to come back at 40hours/week. You can't solve anything with a workforce that's hardly capable of bashing on the keyboard because they're so overworked.

The proprietary tools, however, list things such as implicit casts and sizeof'ing a string literal. Implicit casts are also blacklisted on their stylebook.

You really need to either just drop the tool entirely, or reconfigure/replace it. Warning on every implicit cast is far too much for anyone to deal with.