Previously we were using the same set of conditions
for serializing as for swiftdoc, so excluded them.
However it's reasonable to have them in the
swiftsourceinfo.
Only return macros that are valid in their current position, ie. an
attached macro is not valid on a nominal.
Also return freestanding expression macros in code block item position
and handle the new freestanding code item macros.
Resolves rdar://105563583.
Introduce SingleValueStmtExpr, which allows the
embedding of a statement in an expression context.
This then allows us to parse and type-check `if`
and `switch` statements as expressions, gated
behind the `IfSwitchExpression` experimental
feature for now. In the future,
SingleValueStmtExpr could also be used for e.g
`do` expressions.
For now, only single expression branches are
supported for producing a value from an
`if`/`switch` expression, and each branch is
type-checked independently. A multi-statement
branch may only appear if it ends with a `throw`,
and it may not `break`, `continue`, or `return`.
The placement of `if`/`switch` expressions is also
currently limited by a syntactic use diagnostic.
Currently they're only allowed in bindings,
assignments, throws, and returns. But this could
be lifted in the future if desired.
Fix a crash that could occur when performing
completion at the start of an accessor body.
Previously we assumed `CodeCompletion` would never
be null due to function body skipping in the first
pass of code completion. However with the
introduction of the ability to avoid skipping in
certain cases, it might be now be null if we need
to avoid skipping. Found by the stress tester.
rdar://95772803
These declaration modifiers are not meant to be used from user source
code. Mark them 'UserInaccessible' so code completion don't show them.
rdar://92970201
Previously 'actor' keyword was suggested as (deprecated) 'actor' decl
modifier, and it was gated by '-enable-experimental-concurrency'
compiler argument.
Add 'actor' as a type decl introducer. This causes duplicated 'actor' in
code completion if '-enable-experimental-concurrency', but that option
is basically useless at this point, so I assume not many people is using
it. Also 'actor' as a modifier will be removed soon.
[#58520] rdar://92511769
Tweaked usable check:
* Local type/func decls are usable even before declaration
* Outer nominal Instance member are not usable
* Type context cannot close over values in outer type contexts
Added shadowing rule by the base name:
* Type members don't shadow each other as long as they are in the
same type context.
* Local values shadow everything in outer scope
* Except that 'func' decl doesn't shadow 'var' decl if they are in the
same scope.
rdar://86285396
I think that preferring identical over convertible makes sense in e.g. C++ where we have implicit user-defined type conversions but since we don’t have them in Swift, I think the distinction doesn’t make too much sense, because if we have a `func foo(x: Int?)`, want don’t really want to prioritize variables of type `Int?` over `Int` Similarly if we have `func foo(x: View)`, we don’t want to prioritize a variable of type `View` over e.g. `Text`.
rdar://91349364
Two paths missed setting up overlays:
- `CompletionInstance` when checking files from dependencies
- `SwiftASTManager` when reading in files that it would later replace
all inputs with
(1) would cause the AST context not to be re-used, even though nothing
had changed. (2) caused all non-completion functionality to fail for any
symbols within files only specified by the overlay.
Resolves rdar://85508213.
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
Computing the type relation for every item in the code completion cache is way to expensive (~4x slowdown for global completion that imports `SwiftUI`). Instead, compute a type’s supertypes (protocol conformances and superclasses) once and write their USRs to the cache. To compute a type relation we can then check if the contextual type is in the completion item’s supertypes.
This reduces the overhead of computing the type relations (again global completion that imports `SwiftUI`) to ~6% – measured by instructions executed.
Technically, we might miss some conversions like
- retroactive conformances inside another module (because we can’t cache them if that other module isn’t imported)
- complex generic conversions (just too complicated to model using USRs)
Because of this, we never report an `unrelated` type relation for global items but always default to `unknown`.
But I believe this change covers the most common cases and is a good tradeoff between accuracy and performance.
rdar://83846531
Instead of checking that the stdlib can be loaded in a variety of places, check it when setting up the compiler instance. This required a couple more checks to avoid loading the stdlib in cases where it’s not needed.
To be able to differentiate stdlib loading failures from other setup errors, make `CompilerInstance::setup` return an error message on failure via an inout parameter. Consume that error on the call side, replacing a previous, more generic error message, adding error handling where appropriate or ignoring the error message, depending on the context.
Essentially, just wire up cancellation tokens and cancellation flags for `CompletionInstance` and make sure to return `CancellableResult::cancelled()` when cancellation is detected.
rdar://83391488
We had some situations left that neither returned an error, nor called the callback with results in `performOperation`. Return an error in these and adjust the tests to correctly match the error.
* "description" for override completion is now annotatable
* "description" doesn't include attributes and decl introducer, but it
includes generic paramters, effects specifiers, result type clause,
and generic where clauses
* "name" now only include the name and the parameter names
* "sourcetext" should be the same
rdar://63835352
`CodeCompletioString::getName()` was used only as the sorting keys in
`CodeCompletionContext::sortCompletionResults()` which is effectively
deprecated. There's no reason to check them in `swift-ide-test`. Instead,
check `printCodeCompletionResultFilterName()` that is actually used for
filtering.
The patch introduces a new setting instead of changing existing settings
because the generated interfaces in the IDE have slightly different
requirements; the extended type there is unconditionally not printed
qualified (even if it is ambiguous). This is likely because the
ambiguity heuristic is very weak; it doesn't even do name lookup.
Simplifying that logic would be nice, but then we'd need to update
a bunch of IDE/print* tests and end up with more more visual clutter
in the IDE.
Introducing the new setting means we can change the behavior for
swiftinterface files without affecting the behavior for IDE interfaces.
Fixes rdar://79093752.
The notion of "actor-isolated" currently exists at the declaration level.
For functions, it is going to be captured in the function type itself,
where 'self' is declared to be 'isolated'. Model isolation both
ways: the 'self' of a method that is isolated to an actor instance
will be 'isolated' as well.
We are still using declaration-based checking of actor isolation.
However, by mirroring this information we can move more incrementally
over to doing checking based on 'isolated' parameters.
'InvalidAsyncContext' depends on the decl context. That may case
"sticky" not-recommended If it's cached for a non-async context.
To workaround this, stop checking 'InvalidAsyncContext' when collecting
completion items for caching. Also consistently use the 'SourceFile' as
the decl context to avoid decl context specific behavior.
rdar://78315441
When matching an argument to a parameter list, if there is no matching
parameter, the argument list is not applicable to the parameters. In
such case, code completion should not suggest argument labels of the
function.
rdar://77867723
For example, non-Darwin platforms probably don't want
`#colorLiteral(red:green:blue":alpha:)` and `#imageLiteral(named:)`.
Add an completion option to include them, which is "on" by default.
rdar://75620636
Previously, completing inside non single expression body might cause a
crash if you had done any completion with single expression in the same
body.
e.g.
func test() {
test(#^HERE^#)
}
after that:
func test() {
test(arg)
if #^HERE^#
}
That was because the `hasSingleExpressionBody` wasn't cleared when
reusing the function for subsequent completions.
This patch just clears it whenever a new parsed body is set to a
function.
rdar://75358153
struct Foo {
init(_ arg1: String, arg2: Int) {}
init(label: Int) {}
}
func test(strVal: String) {
_ = Foo(<HERE>)
}
In this case, 'strVal' was prioritized because it can use as an argument
for 'init(_:arg2:)'. However, argument labels are almost always
preferable, and if the user actually want 'strVal', they can input a few
characters to get it at the top. So we should always prioritize call
argument patterns.
rdar://77188260
The diagnosticc engine is keeping track of state which might modify parsing/typechecking behaviour. In the added test case the `fatalErrorOccurred` flag was during the first completion. The flag was still `true` for the second completion, causing parsing/typechecking to behave slightly differently. Because of this, the ExprRewriter failed when applying a constraint system solution, not properly cleaning up its `ExprStack`.
This PR tackles both issues:
1) Reset the `hadError` flags in the diagnostics engine
2) Clean up the `ExprRewriter`’s `ExprStack` when rewriting a target fails.
Either of these changes fixes the crash in the test case but I think both could manifest through different code paths in different scenarios.
Fixes rdar://76051976 [SR-14430]
