Some invalid specializations were previously allowed by the compiler
and we found some existing code that used that (albeit invalid) syntax,
so we need to stage that error as a warning until Swift 6 language mode
to avoid source compatibility break.
Resolves: rdar://134740240
The reason why I am making this change is because I want to put a merge
operation on DiagnosticBehavior. This merge operation allows for
DiagnosticBehavior to work like a lattice. When one merges, one moves
potentially from fatal, error to things like note, ignore.
Always add constraints, find fixes during simplify.
New separate fix for allow generic function specialization.
Improve parse heuristic for isGenericTypeDisambiguatingToken.
Degrade concrete type specialization fix to warning for macros.
Always add constraints, find fixes during simplify.
New separate fix for allow generic function specialization.
Improve parse heuristic for isGenericTypeDisambiguatingToken.
Control enforcement of member import visibility requirements via a new option,
instead of piggy-backing on the existing IgnoreAccessControl option. Adopt the
option when doing fallback lookups for unviable members so that the compiler
can diagnose the reason that a member is inaccessible more reliably.
Previously, with MemberImportVisibility enabled decls with the package access
level could be mis-diagnosed as inaccessible due to their access level when
really they were inaccessible due to a missing import.
Resolves rdar://131501862.
Make sure `CouldNotInferPlaceholderType` can
produce a diagnostic for a `PlaceholderType`
locator element, and avoid emitting an extra
diagnostic for a placeholder type in an invalid
position.
Fix the problem that when the only module can be found is an
invalid/out-of-date swift binary module, canImport and import statement
can have different view for if the module can be imported or not.
Now canImport will evaluate to false if the only module can be found for
name is an invalid swiftmodule, with a warning with the path to the
module so users will not be surprised by such behavior.
rdar://128876895
This will ensure that we do not break anyone who has adopted APIs like
CheckedContinuation.resume that now have sending parameters.
An example of where this can come up is shown by the ProcessType in SwiftToolsCore:
```swift
@available(macOS 10.15, iOS 13.0, tvOS 13.0, watchOS 6.0, *)
@discardableResult
public func waitUntilExit() async throws -> ProcessResult {
try await withCheckedThrowingContinuation { continuation in
DispatchQueue.processConcurrent.async {
self.waitUntilExit(continuation.resume(with:))
}
}
}
```
This fails to compile since self.waitUntilExit doesn't expect a function that
takes a sending parameter. We want to give people time to fix such issues.
For unresolved member completion, we were preferring
the more general type, when we ought to be preferring
the more specific type. Additionally, for both
unresolved member and postfix completion we were
opening archetypes, which doesn't work as expected
since we don't compare requirements. Factor out
the logic that deals with merging base types for
lookup, and have it prefer either the subtype, or
the optional type in the case of optional promotion.
rdar://126168123
Removing the old, ad-hoc diagnostics code improves the diagnostics we
emit, since the existing diagnostics for missing conformances is already
pretty good.
rdar://127369509
There are a number of implicit conversions in Swift, such as to Optional
and to an existential, which are now possible for noncopyable types.
But all type casts are consuming operations for noncopyable types. So
it's confusing when a function that takes a borrowed argument of
optional type appears to be consuming:
```
func f(_ x: borrowing NC?) { ... }
let x = NC()
f(x)
f(x) // error!
```
So, rather than for people to write `x as T?` around all implicit
conversions, require them to write `consume x` around expressions
that will consume some lvalue. Since that makes it much more clear what
the consequences will be.
Expressions like `f(g())`, where you're passing an rvalue to the callee,
are not confusing. And those are exactly the expressions you're not
allowed to write `consume` for, anyway.
fixes rdar://127450418
Type variable reference collector needs to be augmented to collect
type variables associated with pack expansions that a closure references
elements of, otherwise it would get disconnected from the context.
When a retroactive conformance to a protocol that inherits from `Sendable`
introduces an implicit `Sendable` conformance, allow `@preconcurrency`
to suppress the diagnostic about the `Sendable` conformance being
introduced outside of the original source file.
Fixes rdar://125080066.
The "send non-Sendable" pass had a copy of the code for determining
what limit to put on the diagnostic behavior for a given reference to
a nominal type declaration. Rather than update that copy for the
recent changes to the canonical version of this in the type checker,
share the computation.
Instance properties of non-sendable types cannot safely be
accessed within deinitializers. Make sure we respect `@preconcurrency`
when diagnosing these.
Stored `let` properties of a struct, class, or actor permit
'inout' modification within the constructor body after they have been
initialized. Tentatively remove this rule, only allowing such `let`
properties to be initialized (assigned to) and not treated as `inout`.
Fixes rdar://127258363.
This change is two fold. Firstly it enables collection of exported
imports from non source file units. Additionally this recurses through
the exported imports to ensure the transitive set is collected.
Fixes https://github.com/apple/swift/issues/59920
rdar://89687175
This translates the rules for @preconcurrency import from SE-0337 into the
region isolation world. Specifically if a module is compiled without strict
concurrency checking and imported with @preconcurrency:
1. All types from that module that are implicitly non-Sendable have diagnostics
suppressed in swift 5 and swift 6.
2. All types from that module that are explicitly non-Sendable emit warnings in
both swift 5 and swift 6.
rdar://126804052
The reason why I am doing this is that I am going to be adding support for
preconcurrency imports to TransferNonSendable. That implies that we can have
preconcurrency import suppression in the SIL pipeline and thus that emitting the
diagnostic in Sema is too early.
To do this, I introduced a new module pass called
DiagnoseUnnecessaryPreconcurrencyImports that runs after the SILFunction pass
TransferNonSendable. The reason why I use a module pass is to ensure that
TransferNonSendable has run on all functions before we attempt to emit these
diagnostics. Then in that pass, we iterate over all of the modules functions and
construct a uniqued array of SourceFiles for these functions. Then we iterate
over the uniqued SourceFiles and use the already constructed Sema machinery to
emit the diagnostic using the source files.
rdar://126928265
To compute the expected type of a call pattern (which is the return type of the function if that call pattern is being used), we called `getTypeForCompletion` for the entire call, in the same way that we do for the code completion token. However, this pattern does not generally work. For the code completion token it worked because the code completion expression doesn’t have an inherent type and it inherits the type solely from its context. Calls, however, have an inherent return type and that type gets assigned as the `typeForCompletion`.
Implement targeted checks for the two most common cases where an expected type exists: If the call that we suggest call patterns for is itself an argument to another function or if it is used in a place that has a contextual type in the constraint system (eg. a variable binding or a `return` statement). This means that we no longer return `Convertible` for call patterns in some more complex scenarios. But given that this information was computed based on incorrect results and that in those cases all call patterns had a `Convertible` type relation, I think that’s acceptable. Fixing this would require recording more information in the constraints system, which is out-of-scope for now.
This avoids a crash that could occur when
attempting to query their interface type later,
which could cause us to attempt to type-check
the Decl separately from its enclosing closure.
Eventually we also ought to use this to fill in
ErrorTypes for expressions (since type-checking
ought to only produce typed AST), but I'm leaving
that as future work for now.
rdar://120012473
