This is yet another problem caused by the fact compilers have a 'file in, file out' interface.
(the other problem is performance of
the compilation/linking/packaging process). There's simply no reason why input to a compiler should be a file, and no reason why the result should be one.
Suppose the IDE has the code in memory, it wants it compiled (or syntax checked, or ...). Currently, it needs to write out a file, then call the compiler, and pick up the result from the file system, and parse the result. Ideal, would be a programmer's API to do this. But a compilation service, with RPC calls would already be a major improvement.
Also, if you store code, intermediate results, dependencies, ..., in a database (could even be in memory), you can reuse these intermediate results. The dependency graph can guide you to decide what needs to be changed etc.
I'm not seeing the problem. You can already pipe inputs to the compiler, and those inputs don't have to be from a file on-disk, they can just be fed over stdin. Several compilers, including GCC, support using in-memory only movement of interstitial data between compilation phases instead of using intermediate temp files.
