search for: d1587

...capsulate the "command line" side in LinkerInput, that means the "logical" path used for error reporting and the buffers associated with the input. The resolver side should not be involved with either. I see D1598 (changing parseFile to take LinkerInput) as necessary step toward D1587 and related changes, i.e. the ability to properly represent positional flags and hand that information down. This now leaves out the question whether the command line view and the resolver view should have the same classes or not. I am not at the point yet where I can tell what the best behavior i...

I do think we have too many classes. I thought InputGraph was going to replace InputFiles. It seems link LinkerInput could be merged into FileNode. Originally InputFiles was the abstract interface that he Resolver used to see all the inputs. If InputGraph supported the methods forEachInitalAtom() and searchLibraries() then we could get rid of InputFiles and have the Resolver uses InputGraph

Hi, With the inputGraph now, lld models command line options, input files as nodes in the InputGraph called InputElements. In the current approach, each InputElement is converted to a LinkerInput, which works if all lld deals with individual files. Dealing with ControlNodes (Groups), have a problem with it, on how to model that as a LinkerInput. Joerg/Me were chatting on the IRC about this