Implement --start-lib and --end-lib.
General idea sounds reasonable, but we have to make sure it works with bitcode too.
Why do you need this?
So, --start-lib foo.bc --end-lib should work. This suggests that it should be a flag in the class saying that it is lazy, not a new type.
It should be possible to use bitcode files in --start-lib/--end-lib, so this should inherit from InputFile, like ArchiveFile does
It can then have two subclasses or just know that it can be wrapping a .o or a .bc.
Updated as per review comments.
Reusing the existing File classes for lazy files was not easy as I expected. For example, the existing parse function takes a list of COMDAT group names. When creating lazy files, we don't want to read or write the list because parsing a lazy file should have any semantic meaning. Therefore, it seems to be easier to keep LazyObjectFile as a separate class than making a flag.
This patch worked when I made a change to handle each file in an archive file using LazyObjectFile instead of ArchiveFile (with a few exception related to error messages containing an archive file name), so it looks like it's working fine for regular object files and bitcode files.