Briefly describe all of the formats in SupplementaryOutputPaths.h. #18187
Conversation
| /// This is a JSON-based format that is used by the migrator, but is not | ||
| /// really vetted for anything else. | ||
| /// | ||
| /// \sa swift::writeEditsInJson | ||
| std::string FixItsOutputPath; |
There was a problem hiding this comment.
@nkcsgexi This format could use some documentation somewhere, even if includes a disclaimer about using it for anything else!
| /// This is a JSON-based format that encodes which modules have been loaded. | ||
| /// It's based on the same file-based information as the Make-style | ||
| /// dependencies. | ||
| /// | ||
| /// It is currently only used with WMO, but could be generalized. | ||
| std::string LoadedModuleTracePath; |
There was a problem hiding this comment.
@huonw This format could use documentation somewhere, even if we want to say "the details are subject to change because Apple uses it for things".
There was a problem hiding this comment.
When I read "currently only used with WMO", I wonder what it's used for with WMO, and why not with other modes? (Don't know the best place to explain, though.)
There was a problem hiding this comment.
Does somewhere include here? If so:
The file is appended to, and consists of line-delimited JSON objects, where each line is of the form
{ "name": NAME, "target": TARGET, "swiftmodules": [PATH, PATH, ...] }, representing the (real-path)PATHs to each.swiftmodulethat was loaded while building moduleNAMEfor targetTARGET. This format is subject to arbitrary change.
Also, I think the "only used with WMO" comment is now wrong. It is only used with the first frontend invocation, but it works for incremental and WMO.
There was a problem hiding this comment.
Sure, I can include that.
| /// | ||
| /// Only makes sense when the compiler has whole-module knowledge. | ||
| /// | ||
| /// \sa swift::writeTBDFile | ||
| std::string TBDPath; |
There was a problem hiding this comment.
I'll poke the Clang folks to see if there's any documentation I can link to.
There was a problem hiding this comment.
…apparently there isn't today. Oh well.
There was a problem hiding this comment.
I want to say (may not be accurate) "consumed by the driver to optimize linking" or whatever the accurate version is.
There was a problem hiding this comment.
"which clients can link against without having an actual dynamic library binary" doesn't cover that? (It's consumed by the linker.)
There was a problem hiding this comment.
Sorry, I had read the conversation and somehow didn't see that. In my ignorance, I'm left wondering how a client can link against something without a library binary? But that's not needed here. So, would the TBD file be used by "ld"?
There was a problem hiding this comment.
Yes, the Apple linker ld/ld64 has support for these text-based stubs, and, as Jordan says, it can consume them for linking.
There was a problem hiding this comment.
Yep. Whether or not that's supported is an implementation detail of a particular linker, though. I'm pretty sure Apple's ld64 and maybe LLVM's lld are the only ones.
|
@swift-ci Please smoke test |
jrose-apple
force-pushed
the
supplementary-information
branch
from
be476de to
a0a1435
Compare
|
@swift-ci Please smoke test |
Prompted by #18090. Note that the docs for
ModuleInterfaceOutputPathare still a little sparse because I'm going to add a "see also" link very soon. That newswift::emitModuleInterfacewill have the link to the forum post.