2025-09-28 –, Auditorium B003 (170)
A proof-of-concept demonstration of a language-independent metadata database to support source-code interrogation and navigation. Such a database could support little-understood source-code analysis and functionality that is not available today at any price.
I propose that GCC be extended to produce such a database, probably from the gimple tree, as an affordance to tool developers.
Tool development for C++ in particular died on the vine in the 1990s, a victim of industry factors and perception. Today, commonly used tools like cscope and etags cannot distinguish between std::find and std::map::find. The etags file format was last updated in 1998 and in the introduction to its manual lists support for C++ as a desirable feature.
Even if these broken tools worked on their own terms, they would still be inadequate. Static analysis can show, for example, everywhere a variable is modified, and where its address is taken so that it could be modified, and the code paths by which that modification is effected. Static analysis can prove that a variable is not modified or a function is not called from some arbitrary module.
But no tool does those things. A moment's consideration reveals why: to analyze, say, C++, a tool must first parse C++, a famously difficult proposition. For GCC, though, that is a solved problem. Let's externalize what the gcc parsers do, so tool developers can exploit them.
James worked for many years on Wall Street on quantitative research systems, implementing algorithms and designing databases to support them. For a decade he was the maintainer for FreeTDS (www.freetds.org), a client library for SQL Server. For the last several years, he's been extending gcc to recognize COBOL, with the (so far) secret ambition of enticing mainframe shops to embrace GCC and Linux.