On 13/02/18 03:10, Martin Sebor wrote:
PS Is there any reason why diagnostic-core.h and diagnostic.c does not/should not include tree.h and other GCC headers?
The short reason is that we want to keep the core diagnostics as independent of the rest of the compiler as possible so that using it doesn't bring undesired dependencies. It took some effort a few years ago to clean-up headers, in particular, the mess of toplev.h, inclusion of rtl in FE files, inclusion of tree.h in back-end files, etc. I'm not sure what is the status now but I'm afraid that without any definition of actual internal/external interfaces and without actual physical separation of files and compilation steps (read: libraries), the headers may have crept back in.
Long time ago there was a plan of making GCC more modular, perhaps moving to a library framework like LLVM/Clang. I even had a patch that moved all core diagnostics and line-map stuff to its own libdiagnostic that was used by libcpp and the rest of the compiler (instead of overriding call-backs in libcpp like we do now and forcing libcpp into every executable that wishes to use diagnostics or line-maps). Unfortunately, it never worked properly because of the build machinery.
More background (probably very much outdated and forgotten): https://docs.google.com/document/pub?id=1ZfyfkB62EFaR4_g4JKm4--guz3vxm9pciOBziMHTnK4 https://gcc.gnu.org/wiki/rearch https://gcc.gnu.org/wiki/ModularGCC Cheers, Manuel.