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
(cherry picked from commit 44aba1382d)
Raw identifiers are backtick-delimited identifiers that can contain any
non-identifier character other than the backtick itself, CR, LF, or other
non-printable ASCII code units, and which are also not composed entirely
of operator characters.
Introduce a new deserialization mode `enableExtendedDeserializationRecovery`
for use when we can afford inconsistent information from a swiftmodule
file. It's enabled automatically in debugger mode, when user errors are
allowed and during index-while-building.
References for function calls where there would normally be a received-by relationship were being discarded. This happened when the receiver type is a non-indexed type, e.g. a private type in a system framework. The function call could be public or defined in any module though, so discarding it entirely because of the receiver type is not desirable.
Follow up to refine the behavior of [previous commit](b65d8c212e).
Indexing while building sometimes triggers module deserialization issues, exemplified
by a recent issue of rdar://141357099. This change introduces the blocklist support
to avoid indexing specific module names so we could rely on external data source for
unblocking builds, instead of modifying the compiler source.
Resolves: rdar://143770366
Normally references to initializers of collections like Array and Dict are emitted into the index data. It was missing any initializer called using the collection's literal type resentation instead of the type name.
For example:
```
_ = Array<Int>(repeating: 0, count: 1) // Reference is emitted.
_ = [Int](repeating: 0, count: 1) // Reference is missing.
```
This PR fixes the inconsistency by emitting references for those collection intializers.
fixes#68974
Based on feedback in PR https://github.com/swiftlang/swift/pull/69460, enabling indexing for synthesized decls because they are usable by users and make sense to appear in the indexstore.
Sets `synthesized` on some additional decls:
- derived `hashInto(...)`
- Objc properties and methods derived from Objc protocols
https://github.com/apple/swift/issues/67446
Track the original-decl/captured decl as part of the symbol passed to the IndexConsumer. This allows the Rename consumer to check if the symbol is a shadowed reference to a decl being renamed, without the index skipping the other relevant output when visiting shadowing variables.
https://github.com/swiftlang/swift/issues/76805
The "buffer ID" in a SourceFile, which is used to find the source file's
contents in the SourceManager, has always been optional. However, the
effectively every SourceFile actually does have a buffer ID, and the
vast majority of accesses to this information dereference the optional
without checking.
Update the handful of call sites that provided `nullopt` as the buffer
ID to provide a proper buffer instead. These were mostly unit tests
and testing programs, with a few places that passed a never-empty
optional through to the SourceFile constructor.
Then, remove optionality from the representation and accessors. It is
now the case that every SourceFile has a buffer ID, simplying a bunch
of code.
I recently accidentally broke this, make sure
we carve out an exception for pseudo accessors in
`shouldIndex` such that we record e.g override
relations for them.
rdar://131749546
These won't have bodies in generated interfaces,
and generally aren't useful things to jump to. The
property ought to be used instead.
rdar://130775560
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
For example, the following declarations have the same USR with a single ERROR_TYPE parameter despite being distinct declarations.
```swift
func bar(body: Invalid) {}
func bar(ignoreCase: Bool, body: Invalid) {}
```
We originally intended to check the USR so that local rename behaves more like global rename, which also looks symbols up by USR. But the above example proves that assumption wrong.
rdar://126803702
Check to see whether we can index the given decl
before reporting it as a container, walking up to
a parent if we need to. This also lets us simplify
the AnyPattern handling a bit.
rdar://126137541
Wrap the `InheritedEntry` array available on both `ExtensionDecl` and
`TypeDecl` in a new `InheritedTypes` class. This class will provide shared
conveniences for working with inherited type clauses. NFC.
This is a futile attempt to discourage future use of getType() by
giving it a "scary" name.
We want people to use getInterfaceType() like with the other decl kinds.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Macro-generated extensions are hoisted to file scope, because extensions are
not valid in nested scopes. Callers of 'visitAuxiliaryDecls' assume that the
auxiliary decls are in the same decl context as the original, which is clearly
not the case for extensions, and it leads to issues like visiting extension at
the wrong time during SILGen. The extensions are already added to the top-level
decls, so we don't need to visit them as auxiliary decls, and we can type-check
macro-expanded decls at the end of visitation in TypeCheckDeclPrimary.
The code to remove these subsumed properties was part of creating the
memberwise initializer declaration, which could lead to
inconsistencies with the newly-introduced request for gathering the
memberwise-initialized properties. Move the code into the computation
of the list of memberwise-initialized properties.
Also update a few more places that were effectively recomputing the
set of memberwise-initialized properties themselves over to the
request.
Previously only the type underlying the typealias was included in the
index data. Now the extension of a typealias includes 2 entries, 1 for
the underlying type and one for the typealias definition.
Fixes https://github.com/apple/swift/issues/64594
Pass back the original location (ie. where the macro was expanded, not
the location that the generated code would be inserted) for cursor info
and indexing. Also mark any declarations/references within generated
source as implicit.
Resolves rdar://107209132.
