https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85716
--- Comment #15 from David Malcolm <dmalcolm at gcc dot gnu.org> --- Brainstorming some ideas here: LSP has an interface for reporting progress notifications; see: https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#workDoneProgress The various programs launched by the driver could report back to it with progress notifications (maybe via a unix domain socket specified via an environment var?) Presentation: the driver could see if it's connected to a TTY and if things are taking above a threshold start displaying/refreshing a line showing the progress information, perhaps e.g.: [====== ] 50% : cc1: expand: some_function_name showing estimated overall % complete; what current tool is, for cc1 what current pass and funtion is; or somesuch. Maybe show: - wallclock time elapsed - number of "items" done vs overall number of "items" to be done (hence able to show %), where what an "item" is would vary Or the driver could re-report the notifications back to another LSP consumer (e.g. an IDE, or to "make") Could have some kind of rate-limiting on the IPC so that we're sending IPC across the protocol at a time-based frequency, rather than doing it for every (pass,function) pair, since that would presumably introduce lots of overhead. Could have gcc driver, cc1 etc, gas, ld, LTO all co-operate in this so that e.g. the user gets meaningful progress information on a big LTO compile. Maybe event teach GNU "make" about this, so that the user can receive "integrated" progress reports from a parallel make. (If so, probably want the protocol to support parallel work) (this is just a brainstorm; no guarantees about implementing any of this)
