This commit changes fixit messages from a question/suggestion to an
imperative message for protocol conformances and switch-case. Addresses
https://github.com/apple/swift/issues/67510.
The restriction that default arguments be disallowed from accessing
`@usableFromInline` decls is overbearing for library developers who need to
write non-trivial code to compute a default value, since it forces them to
either write a verbose closure inline in the function signature or expose a
`public` helper function which unnecessarily expands API surface. A
`@usableFromInline` function a more reasonable way to encapsulate a verbose
default value computation.
This reverses the semantic changes included in https://github.com/apple/swift/pull/15666.
Resolves rdar://112093794.
And adjust contextual parameter modifier parsing in general to be more
properly contextual, so we don't have to reserve `__shared` or `__owned`,
or their successor spellings, as argument labels anymore.
Introduce a `getTopmostDeclarationDeclContext`
utility to ensure we ensure we don't visit a
`nullptr` DeclContext for an erroneous module
under `-experimental-allow-module-with-compiler-errors`.
Additionally, tweak the insertion location such
that we insert at the start of any attributes
present.
rdar://97267326
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
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
When recovering from a parser error in an expression, we resumed parsing at a '{'. I assume this was because we wanted to continue inside e.g. an if-body if parsing the condition failed, but it's actually causing more issue because when parsing e.g.
```swift
expr + has - error +
functionTakesClosure {
}
```
we continue parsing at the `{` of the trailing closure, which is a completely garbage location to continue parsing.
The motivating example for this change was (in a result builder)
```swift
Text("\(island.#^COMPLETE^#)")
takeTrailingClosure {}
```
Here `Text(…)` has an error (because it contains a code completion token) and thus we skip `takeTrailingClosure`, effectively parsing
```swift
Text(….) {}
```
which the type checker wasn’t very happy with and thus refused to provide code completion. With this change, we completely drop `takeTrailingClosure {}`. The type checker is a lot happier with that.
if there is a non-null callee.
Otherwise, getParameterList(callee) will crash if the callee is a closure.
Closures can't have default arguments anyway, so there's no need to
attempt this new inference.
Insert an implicit conversion from pack types to tuples with equivalent parallel structure. That means
1) The tuple must have the same arity
2) The tuple may not have any argument labels
3) The tuple may not have any variadic or inout components
4) The tuple must have the same element types as the pack
In Swift 5.4, this worked:
func foo(_: (() throws -> ())? = nil) rethrows {}
foo() // no 'try' needed
However, this was an accident, because this was also accepted:
func foo(_: (() throws -> ())? = { throw ... }) rethrows {}
foo() // 'try' *should* be required here
This got fixed at some point recently, but since people rely on the
old case working for 'nil', let's add back a check for a 'nil'
default parameter.
Fixes rdar://problem/76169080.
The first test case added ideally shouldn't have any expected error or diagnostic.
However, due to SR-1534, there is an error emitted here. Thus, an expected error is
used here to show the compiler's behavior today.
If SR-1534 is fixed in the future, the first test case should no longer have any
expected error nor an expected note. However, the second test case should still be
left alone.
Addresses SR-14270
To help support incremental adoption of the concurrency model, a number
of concurrency-related diagnostics are enabled only in "new" code that
takes advantage of concurrency features---async, @concurrent functions,
actors, etc. This warning flag opts into additional warnings that better
approximate the eventual concurrency model, and which will become
errors a future Swift version, allowing one to both experiment with
the full concurrency model and also properly prepare for it.
