With the unqualified fallback we start to hit this assertion for
`return nil` in failable intializers. We ought to be able to just
skip over literal buckets though.
For hosts that have a swiftly-managed Swift compiler, we could not
bootstrap using those tools, because of some hardcoded assumptions
about where the `/lib` directory lives, relative to the `/bin`
directory that contains the detected `swiftc`.
This patch adds specific support for detecting when the `swiftc`
is coming from a swiftly install and uses the correct paths.
I've tested this patch on my Linux machine that has swiftly 1.0.1,
with the Swift 6.1.2 toolchain.
The sourcekit in proc dynamic library looks up runtimes in a spot
relative to the Swift compiler. Set this location on freebsd, fixing the
sourcekit tests.
Currently, when we jump-to-definition for decls that are macro-expanded
from Clang imported decls (e.g., safe overloads generated by
@_SwiftifyImport), setLocationInfo() emits a bongus location pointing to
a generated buffer, leading the IDE to try to jump to a file that does
not exist.
The root cause here is that setLocationInfo() calls getOriginalRange()
(earlier, getOriginalLocation()), which was not written to account for
such cases where a macro is generated from another generated buffer
whose kind is 'AttributeFromClang'.
This patch fixes setLocationInfo() with some refactoring:
- getOriginalRange() is inlined into setLocationInfo(), so that the
generated buffer-handling logic is localized to that function. This
includes how it handles buffers generated for ReplacedFunctionBody.
- getOriginalLocation() is used in a couple of other places that only
care about macros expanded from the same buffer (so other generated
buffers not not relevant). This "macro-chasing" logic is simplified
and moved from ModuleDecl::getOriginalRange() to a free-standing
function, getMacroUnexpandedRange() (there is no reason for it to be
a method of ModuleDecl).
- GeneratedSourceInfo now carries an extra ClangNode field, which is
populated by getClangSwiftAttrSourceFile() when constructing
a generated buffer for an 'AttributeFromClang'. This could probably
be union'ed with one or more of the other fields in the future.
rdar://151020332
Most `SemaAnnotator`s don’t actually care about the char source range. Instead, they only care about the start location of the reference, which is also included in `SourceRange`. Computing a `CharSourceRange` from a `SourceRange` is kind of expensive because it needs to start a new lexer.
To avoid this overhead, pass `SourceRange` to `SemaAnnotator::passReference` and related functions and let the clients compute the `CharSourceRange` when needed.
This reduces the overhead of index-while-building by about 10%.
Make `getOriginalLocation` work with source ranges, and adjust the
cursor info logic to map the range into the original buffer. This
fixes the case where we were using bogus range lengths for macro
expansion decls.
rdar://151411756
Introduce a new ASTWalker option for walking CustomAttrs and use it
for the placeholder scanner to ensure we can expand placeholders in
attribute arguments.
