Make sure we don't ever try to record semantic tokens for a different
buffer. This works around an ASTWalker issue where it will walk macro
expanded bodies even in non-macro-expansion mode.
rdar://165420658
This change just stages in a few new platform kinds, without fully adding
support for them yet.
- The `Swift` platform represents availability of the Swift runtime across all
platforms that support an ABI stable Swift runtime (see the pitch at
https://forums.swift.org/t/pitch-swift-runtime-availability/82742).
- The `anyAppleOS` platform is an experimental platform that represents all of
Apple's operating systems. This is intended to simplify writing availability
for Apple's platforms by taking advantage of the new unified OS versioning
system announced at WWDC 2025.
- The `DriverKit` platform corresponds to Apple DriverKit which is already
supported by LLVM.
Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
Make sure we avoid adding these to the entity stack entirely, which
avoids hitting the assertion that a top-level entity isn't encountered
with a non-empty stack.
This reverts most of 72050c5385, which led to decreased performance of jump-to-definition.
Instead of re-attempting to generate a module interface with C++ interop enabled, Swift should rely on the IDE to pass the correct `-cxx-interoperability-mode=` value to SourceKit.
rdar://149061322
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.
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.
The diagnostic group documentation now point to the swift.org URL rather
than the toolchain path, so it no longer needs to be passed all the way
through sourcekitd.
Resolves rdar://151500502.
We need this option for `collectVariableType` (aka inlay type hints) but since I’m at it, I’m adding an option to disable the implicit request cancellation for all requests that have it since we don’t want it in LSP at all.
Prerequisite to fixing https://github.com/swiftlang/sourcekit-lsp/issues/2021 / rdar://145871554, need to adopt this option in SourceKit-LSP.
If a module has the same `public-module-name` as the module being
generated and its import is exported, merge it into the same generated
interface.
Fix various always-imported modules from being printed while here and
update all the tests that checked for them.
Resolves rdar://137887712.
We've been converging the implementations of educational notes and
diagnostic groups, where both provide category information in
diagnostics (e.g., `[#StrictMemorySafety]`) and corresponding
short-form documentation files. The diagnostic group model is more
useful in a few ways:
* It provides warnings-as-errors control for warnings in the group
* It is easier to associate a diagnostic with a group with
GROUPED_ERROR/GROUPED_WARNING than it is to have a separate diagnostic
ID -> mapping.
* It is easier to see our progress on diagnostic-group coverage
* It provides an easy name to use for diagnostic purposes.
Collapse the educational-notes infrastructure into diagnostic groups,
migrating all of the existing educational notes into new groups.
Simplify the code paths that dealt with multiple educational notes to
have a single, possibly-missing "category documentation URL", which is
how we're treating this.
The Error enum synthesized declarations, e.g. the struct and its static accessors, should generally appear to be identical to the underlying Clang definitions. There are some specific use cases where the synthesized declarations are necessary though.
I've added an option for USR generation to override the Clang node and emit the USR of the synthesized Swift declaration. This is used by SwiftDocSupport so that the USRs of the synthesized declarations are emitted.
Fixes 79912
When a function declaration has a body, its source range ends at the
closing curly brace, so it includes the `throws(E)`. However, a
protocol requirement doesn't have a body, and due to an oversight,
getSourceRange() was never updated to include the extra tokens
that appear after `throws` when the function declares a thrown
error type. As a result, unqualified lookup would fail to find a
generic parameter type, if that happened to be the thrown type.
Fixes rdar://problem/143950572.
