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.
Don't suggest `let` or `var` in e.g the sequence
expression of a `for` loop, or after a `return`.
We ought to do a better job of checking whether
we're in expression position before suggesting
these (as opposed to a pattern), but I'm leaving
that as future work for now.
Instead of querying the ConstraintSystem, query the
Solution instead, as the ConstraintSystem is not
necessarily in the same state as when the solution
was produced.
The constraint system might produce multiple solutions that all reference the same declaration. We should only report the declaration once in those cases instead of multiple times.
rdar://111814276
This patch migrates the compiler off of the deprecated LLVM APIs where I
can.
- APInt::getAllOnesValue -> APInt::getAllOnes
- APInt::getNullValue -> APInt::getZero
- APInt::isNullValue -> APInt::isZero
- APInt::getMinSignedBits -> APInt::getSignificantBits
- clang::Module::submodule_{begin,end} -> clang::Module::submodules
Ignore conversion score increases during code completion to make sure we don't filter solutions that might start receiving the best score based on a choice of the code completion token.
`ASTWalker` was missing a walk into the generic arguments for
freestanding declarations and expressions. `SemaAnnotator` was missing
the walk into the `TypeRepr` when walking over custom attributes.
Resolves rdar://110856428.
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.
When you have a type that's ambiguous because it's defined in 2 imported
modules, but you don't have to disambiguate by using the module name,
previously no index references were produced. Now most are for the
common case, but notably nested type constructors and generics still
aren't emitted, partially because of https://github.com/apple/swift/issues/65726
Fixes: https://github.com/apple/swift/issues/64598
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
In `SourceLookupCache::lookupVisibleDecls`, copy the top level values before iterating them.
If we have 'addinitstotoplevel' enabled, calling 'addConstructorCallsForType' can cause macros to get expanded, which can then cause new members ot get added to 'TopLevelValues', invalidating the current iterator.
I have not been able to reduce this to a test case that doesn’t rely on the `Observation` module in the SDK but here is the test case with which I was able to reproduce the issue very reliably.
```swift
import Foundation
import Observation
@Observable class MyObject {}
extension MyObject {}
// RUN: ~/sbin/sourcekitd-test \
// RUN: -req=complete.open \
// RUN: -req-opts=addinitstotoplevel=1 \
// RUN: -pos=8:1 \
// RUN: %s \
// RUN: -- \
// RUN: %s \
// RUN: -Xfrontend \
// RUN: -load-plugin-library \
// RUN: -Xfrontend \
// RUN: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/lib/swift/host/plugins/libObservationMacros.dylib \
// RUN: -sdk \
// RUN: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX14.0.sdk
```
rdar://109202157
Expand macros in the specified source file syntactically (without any
module imports, nor typechecking).
Request would look like:
```
{
key.compilerargs: [...]
key.sourcefile: <file name>
key.sourcetext: <source text> (optional)
key.expansions: [<expansion specifier>...]
}
```
`key.compilerargs` are used for getting plugins search paths. If
`key.sourcetext` is not specified, it's loaded from the file system.
Each `<expansion sepecifier>` is
```
{
key.offset: <offset>
key.modulename: <plugin module name>
key.typename: <macro typename>
key.macro_roles: [<macro role UID>...]
}
```
Clients have to provide the module and type names because that's
semantic.
Response is a `CategorizedEdits` just like (semantic) "ExpandMacro"
refactoring. But without `key.buffer_name`. Nested expnasions are not
supported at this point.
Previously we would wait until CSApply, which
would trigger their type-checking in
`coercePatternToType`. This caused a number of
bugs, and hampered solver-based completion, which
does not run CSApply. Instead, form a conjunction
of all the ExprPatterns present, which preserves
some of the previous isolation behavior (though
does not provide complete isolation).
We can then modify `coercePatternToType` to accept
a closure, which allows the solver to take over
rewriting the ExprPatterns it has already solved.
This then sets the stage for the complete removal
of `coercePatternToType`, and doing all pattern
type-checking in the solver.
Whe completing in parameter packs, we were calling `getParameterAt` with `Res.FuncDeclRef`. But the substitution map in `Res.FuncDeclRef` contained type variables that were allocated in the constraint system’s arena. And that arena had been freed when we call this from `deliverResults`.
The fix is to compute the optional parameters in advance in `sawSolutionImpl`
rdar://109093909
Previously in the case of a constructor like `A<Int>(value: 1)`
`Fn->getLoc()` returned the location of `>(value: 1)` while the actual
location we're looking for is correctly the start of `A<Int>(value: 1)`.
This adjusts the location we're looking up to use the start location of
the constructor instead.
Fixes: https://github.com/apple/swift/issues/54532
We previously asserted that for a call the function type had the same number of parameters as the declaration. But that’s not true for parameter packs anymore because the parameter pack will be exploded in the function type to account for passing multiple arguments to the pack.
To fix this, use `ConcreteDeclRef` instead of a `ValueDecl`, which has a substitution map and is able to account for the exploded parameter packs when accessed using `getParameterAt`.
rdar://100066716
Showing the type annotation only makes sense if they are not `Void`. That’s consistent with functions where we also don’t show a `Void` return type. Most importantly, we shouldn’t be showing a `Void` type annotation for attached macros.
rdar://108870970
