LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
`toRawComment` takes a range of line/block ordinary/doc comments and
converts them into a `RawComment` that should represent the doc comment
for the attached decl.
Fix a bunch of unhandled cases:
- A prior comment with whitespace in between would cause the first
line of the next comment to be missed
- A gyb comment would attach the prior comment, regardless of
whitespace inbetween
Resolves rdar://82414210
The start and end lines were only used while constructing the comments,
so move the line tracking into that method instead of storing it in each
comment.
- Add DocRangesLayout to the `.swiftsourceinfo`.
This is a blob containing an array of `SingleRawComment`
source locations.
- Add DocLocWriter for serializing `SingleRawComment` locs into the
`DocLocsLayout` buffer.
Serialize start line, start column, and length of `SingleRawComment`
pieces in `.swiftsourceinfo`
- Read doc locs when loading basic declaration locs from a ModuleFile.
- Load `DOC_LOCS` blob into ModuleFile::DocLocsData
- Reconstitute RawComment ranges when available from .swiftsourceinfo
- Allow requesting serialized raw comment if available
rdar://problem/58339492
After this change, we only use one single hash table for USR to USR id
mapping. The basic source locations are an array of fixed length
records that could be retrieved by using the USR id since each
USR id is guaranteed to be associated with one basic location entry.
The source file paths are refactored to a blob of 0-terminated strings.
Decl locations use offset in this blob to refer to the source file path
where the decl was defined.
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
llvm::SourceMgr caches the line and column of the last query. It
usually scans from that position for subsequent queries. However, if the
query is for a position ahead of the last query, it re-scan from the top
of the whole buffer. This significally slows down the performance.
This change effectively mitigate performance regression introduced in
https://github.com/apple/swift/pull/11264 without functional changes.
The driver infers the filename from the module file by replacing the extension,
and passes the explicit path to the swiftdoc file to the frontend. But there
is no option in the driver to control emission of swiftdoc (it is always
emitted, and name is always inferred from the swiftmodule name).
The swiftdoc file consists of a single table that maps USRs to {brief comment,
raw comment}. In order to look up a comment for decl we generate the USR
first. We hope that the performance hit will not be that bad, because most
declarations come from Clang. The advantage of this design is that the
swiftdoc file is not locked to the swiftmodule file, and can be updated,
replaced, and even localized.
Swift SVN r14914
