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
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.
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.
interface for index.
An explicit module build compile is unable to do so because it does not have
access to the interfaces. Doing this in the first place is a workaround for a
known bug, which will require to be solved at the root cause instead (e.g.
Deserialization Safety feature).
Resolves rdar://113165898
The order for writing records of the stdlib currently depends on
`StringMap` iteration (in a slightly roundabout manner). Sort these
alphabetically instead.
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.
Calling getImportedModules requires to list the desired kind of imports.
With the new kind of imports this has become cumbersome. Let's simplify
it by offering common sets of imports. Advanced call sites can still
list the desired imports explicitly.
Rather than using `ModuleDecl::isSystemModule()` to determine whether a
module is not a user module, instead check whether the module was
defined adjacent to the compiler or if it's part of the SDK.
If no SDK path was given, then `isSystemModule` is still used as a
fallback.
Resolves rdar://89253201.
Provide ASTWalker with a customization point to specify whether to
check macro arguments (which are type checked but never emitted), the
macro expansion (which is the result of applying the macro and is
actually emitted into the source), or both. Provide answers for the
~115 different ASTWalker visitors throughout the code base.
Fixes rdar://104042945, which concerns checking of effects in
macro arguments---which we shouldn't do.
Various requests expect to be walking over the current source file.
While we could add checks to all these to skip decls outside of the
current buffer, it's a little nicer to handle this during the walk
instead.
Allow ignoring nodes that are from macro expansions and add that flag to
the various walks that expect it.
Also add a new `getOriginalAttrs` that filters out attributes in
generated source.
If a module was first read using the adjacent swiftmodule and then
reloaded using the swiftinterface, we would do an up to date check on
the adjacent module but write out the unit using the swiftinterface.
This would cause the same modules to be indexed repeatedly for the first
invocation using a new SDK. On the next run we would instead raad the
swiftmodule from the cache and thus the out of date check would match
up.
The impact of this varies depending on the size of the module graph in
the initial compilation and the number of jobs started at the same time.
Each SDK dependency is re-indexed *and* reloaded, which is a drain on
both CPU and memory. Thus, if many jobs are initially started and
they're all going down this path, it can cause the system to run out of
memory very quickly.
Resolves rdar://103119964.
`isAccessibleFrom` has special handling for `@_objcImplementation`
members, which causes the definition in Swift to be missed. Use access
level directly rather than passing `nullptr` into `isAccessibleFrom`.
Update rename to pull the outermost-declaration so that references are correctly found.
Rather than keeping suppressed locations in the current parent, keep
them for the whole index. Local rename starts the lookup from the
innermost context it can, which could be a closure. In that case there
is no parent decl on the stack and thus no where to store the locations
to suppress. We could have a specific store for this case, but there
shouldn't be that many of these and they're relatively cheap to store
anyway.
Resolves rdar://104568539.
Skip the shadowing decl and instead reference the top-most shadowed decl
(ie. follow any shadowed decls up the chain).
Also fix `getShorthandShadows` missing references in `MemberDeclRefExpr`
by using `getReferencedDecl` instead of assuming it is a `DeclRefExpr`.
Resolves rdar://99730146, rdar://100006415, and rdar://103449038.
Local discriminators for named entities are currently being set by the
parser, so entities not created by the parser (e.g., that come from
synthesized code) don't get local discriminators. Moreover, there is
no checking to ensure that every named local entity gets a local
discriminator, so some entities would incorrectly get a local
discriminator of 0.
Assign local discriminators as part of setting closure discriminators,
in response to a request asking for the local discriminator, so the
parser does not need to track this information, and all local
declarations---including synthesized ones---get local discriminators.
And add checking to make sure that every entity that needs a local
discriminator gets assigned one.
There are a few interesting cases in here:
* There was a potential mangling collision with local property
wrappers because their generated variables weren't getting local
discriminators
* $interpolation variables introduced for string interpolation weren't
getting local discriminators, they were just wrong.
* "Local rename" when dealing with captures like `[x]` was dependent on
the new delcaration of `x` *not* getting a local discriminator. There
are funny cases involving nesting where it would do the wrong thing.
Indexing a module from the swiftinterface puts the swiftinterface
version in the cache. Subsequent builds don't see the adjacent
swiftmodule file. This can break test clients that need the adjacent
swiftmodule information. To avoid this scenario, ensure that we only
index system modules in the SDK, not local versions.
rdar://102207620
