Check whether there are any opened generic parameters associated
with a declaration and if not, produce a fix which would be later
diagnosed as either a warning (in Swift 5 mode) or an error (if it
was a concrete type or the compiler is in Swift 6 language mode).
Resolves: rdar://135610320
The error about a public import of a private module is raised when
a library-level API module imports a library-level SPI module without
a non-public access-level, `@_implementationOnly` attribute or
`@_spiOnly` attribute. Update the fixit to insert an `internal` instead
of a `@_implementationOnly`.
`Any` used to be the type used to indicate placeholders before
and that's reflected in the score of the `DefineMemberBasedOnUse`,
this is no longer the same and the impact increase should be dropped.
If the requirement failure is related to an assignment destination
analyze the source of the assignment and if it's a tuple, find the
element and return its type.
If location (member) isn't mutable in the current context
or there are other problems at this location, increase impact
of the fix since it compounds the problem.
- Don't attempt to insert fixes if there are restrictions present, they'd inform the failures.
Inserting fixes too early doesn't help the solver because restriction matching logic would
record the same fixes.
- Adjust impact of the fixes.
Optional conversions shouldn't impact the score in any way because
they are not the source of the issue.
- Look through one level of optional when failure is related to optional injection.
The diagnostic is going to be about underlying type, so there is no reason to print
optional on right-hand side.
Previously, the constraint solver would first attempt member lookup that
excluded members from transitively imported modules. If there were no viable
candidates, it would perform a second lookup that included the previously
excluded members, treating any candidates as unviable. This meant that if the
member reference did resolve to one of the unviable candidates the resulting
AST would be broken, which could cause unwanted knock-on diagnostics.
Now, members from transitively imported modules are always returned in the set
of viable candidates. However, scoring will always prioritize candidates from
directly imported modules over members from transitive imports. This solves the
ambiguities that `MemberImportVisibility` is designed to prevent. If the only
viable candidates are from transitively imported modules, though, then the
reference will be resolved successfully and diagnosed later in
`MiscDiagnostics.cpp`. The resulting AST will not contain any errors, which
ensures that necessary access levels can be computed correctly for the imports
suggested by `MemberImportVisibility` fix-its.
Resolves rdar://126637855.
Prevents a crash when a parameter references an invalid property wrapper. The original code assumed that mutability information would always be available, but this assumption fails when the property wrapper is invalid
Resolves https://github.com/swiftlang/swift/issues/65640
The `_Concurrency` module imports a C module that is not available in the
toolchain or SDK, which means that `@_implementationOnly` must be used to hide
the dependency on this module from clients.
`participatesInInference` is now always true for
a non-empty body, remove it along with the separate
type-checking logic such that empty bodies are
type-checked together with the context.
In the warning about having no try/throw within the body of a do..catch,
replace the walk of the inactive clauses of IfConfigDecl with a syntactic
check of inactive and unparsed regions to look for 'try' and 'throw'
keywords.
This both eliminates a dependency on IfConfigDecl and expands the
usefulness of this warning suppression to unparsed code.
Rather than walking into the inactive regions of IfConfigDecls looking for
references to a declaration before we diagnose it, go to the syntax
tree and look through inactive *and unparsed* regions for identifier
tokens that match. If we find one, suppress the diagnostic.
This reduces our dependency on IfConfigDecl in the AST, and also makes
the same suppression work with code in unparsed regions that had no
representation in IfConfigDecl.
isolation checker.
Previously, the actor isolation checker would crash when attempting to
mark an operator call as implicitly async, because it was specifically
expecting to see a CallExpr. Instead, accept all ApplyExprs except for
SelfApplyExpr.
In #69257, we modified `ObjCReason` to carry a pointer to the @implementation attribute for the `MemberOfObjCImplementationExtension` kind. This made it mark the @implementation attribute as invalid, suppressing diagnostics from the ObjCImplementationChecker.
However, invalidating the attribute *also* causes it to be skipped by serialization. That isn’t a problem if the diagnostics are errors, since we’ll never emit the serialized module, but #74135 softened these diagnostics to warnings for early adopters.
The upshot was that if Swift emitted one of these warnings when it compiled a library, clients of that library would see the objcImpl extension as a normal extension instead. This would cause various kinds of mischief: ambiguous name lookups because implementations weren’t being excluded, overrides failing because an implementation was `public` instead of `open`, asserts and crashes in SILGen and IRGen because stored properties were found in seemingly normal extensions, etc.
Fix this by setting a separate bit on ObjCImplementationAttr, rather than the invalid bit, and modifying the implementation checker to manually suppress many diagnostics when that bit is set.
Fixes rdar://134730183.
Previously, the opaque types in patterns were printed using their full stable
reference which cannot be resolved when parsing a swiftinterface.
Resolves rdar://127771885.
Preserve the warning to use `internal import` instead of `@_implementationOnly`
to imports of Swift modules only. This warning can be noisy, limiting it may
prevent users from outright learning to ignore it. Typical uses of an
`@_implementationOnly` import of a clang module is often for a project
internal module instead of a layering concern as we have with Swift module
targets. We can leave legacy uses of `@_implementationOnly` in peace for now.
The warnings about `using '@_implementationOnly' without enabling library evolution for 'client'
may lead to instability during execution` and `@_implementationOnly' is deprecated, use
'internal import' instead` were wrongly restricted to only Swift import targets.
Make sure they are raised for clang module targets as well.
rdar://135233043
