Commit Graph

6 Commits

Author SHA1 Message Date
Xi Ge
e9dfdea6fd SerializeLoc: serialize basic decl source location information to .swiftsourceinfo file
After setting up the .swiftsourceinfo file, this patch starts to actually serialize
and de-serialize source locations for declaration. The binary format of .swiftsourceinfo
currently contains these three records:

BasicDeclLocs: a hash table mapping from a USR ID to a list of basic source locations. The USR id
could be retrieved from the following DeclUSRs record using an actual decl USR. The basic source locations
include a file ID and the results from Decl::getLoc(), ValueDecl::getNameLoc(), Decl::getStartLoc() and Decl::getEndLoc().
The file ID could be used to retrieve the actual file name from the following SourceFilePaths record.
Each location is encoded as a line:column pair.

DeclUSRS: a hash table mapping from USR to a USR ID used by location records.

SourceFilePaths: a hash table mapping from a file ID to actual file name.

BasicDeclLocs should be sufficient for most diagnostic cases. If additional source locations
are needed, we could always add new source location records without breaking the backward compatibility.
When de-serializing the source location from a module-imported decl, we calculate its USR, retrieve the USR ID
from the DeclUSRS record, and use the USR ID to look up the basic location list in the BasicDeclLocs record.

For more details about .swiftsourceinfo file: https://forums.swift.org/t/proposal-emitting-source-information-file-during-compilation
2019-10-09 15:29:51 -07:00
Harlan Haskins
c82c9b8210 [ModuleInterfaces] Remove references to 'parseable' interfaces everywhere
Now that we've settled on Module Interface as the name, let's remove the
vestiges of "Parseable Interfaces"
2019-09-13 14:55:48 -07:00
Harlan Haskins
fafc5832fe [ModuleInterfaces] ParseableInterfaceModuleLoader -> ModuleInterfaceLoader
Rename this class to better fit the user-facing name.
2019-09-13 13:40:01 -07:00
Jonas Devlieghere
fe2ad03f93 Revert "[ClangImporter] Merge Swift & Clang VFS" 2019-07-05 15:30:43 -07:00
Jonas Devlieghere
f359cef5d0 [ClangImporter] Merge Swift & Clang VFS
The clang importer has to deal with two virtual file systems, one coming
from clang, and one coming from swift. Currently, if both are set, we
emit a diagnostic that we'll pick the swift one.

This commit changes that, by merging the two virtual file systems into a
single overlay file system, and using that. To make this possible, we
always initialize the file manager with an overlay file system. In the
clang importer, we then create a new overlay file system, starting with
the one coming from clang, and adding overlays from swift on top.

The motivation for this change is the reproducer infrastructure in LLDB,
which adds a third virtual file system to the mix.
2019-07-03 17:40:31 -07:00
Harlan Haskins
9ef4b5f358 [ParseableInterface] Add test for writing modules to a buffer 2019-03-22 17:29:11 -07:00