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.
When `MemberImportVisibility` is enabled, if the import that would bring a
member declaration into scope is missing it is diagnosed as an error. The
existing resilience diagnostics that would also diagnose the same problem in
contexts that are visible in the module interface are therefore superflous with
the feature enabled.
In anticipation of adding a new kind of missing import record to `SourceFile`,
clarify the purpose of the existing "missing imports" record with more specific
naming and documentation.
In anticipation of reusing minimum access level information for diagnostics
related to the `MemberImportVisibility` feature, refactor the way the type
checker tracks the modules which must be imported publicly. Recording minimum
access levels is no longer restricted to modules that are already imported in a
source file since `MemberImportVisibility` diagnostics will need this
information when emitting fix-its for modules that are not already imported.
Unblocks rdar://126637855.
Exportability checking for non-public imports relies on classic
access-level checks for some of the work. However while conforming
to a local internal protocol from a public type is allow we should
disallow it for imported types, even when imported as internal.
Track exportability issues on conformances to protocols separately
from the general category. Use that information to improve the
diagnostics and report these issues for access-level on imports.
rdar://128420980
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
This PR treats package access level as exportable, preventing
internally imported types from accidentally being declared in
package decl signatures.
Added package-specific cases to ExportabilityReason and
DisallowedOriginKind to track the validity of imported types
at use sites with package access scope. Added tests to cover
variety of use cases.
Resolves rdar://117586046&125050064&124484388&124306642
Now that the diagnostics are automatically errors in Swift 6, we don't need an
`-enable-conformance-availability-errors` flag to control whether unavailable
conformances are diagnosed as errors. Nobody was using the flag so it should be
safe to remove.
Part of rdar://88210812
Access levels on extensions are special. Let's make sure we report
public extensions referencing non-public imported types using the
preexisting general exportability checks.
Record and remark on the use of the import at the same time.
Using `-Rmodule-api-import` the compiler prints a remark about the
import bringing in every decl used in public function signatures or
inlinable code. It also remarks on the source of conformances where they
are used and the source of typealias underlying types.
Exportability checking logic detects when decls are referenced from API
or inlinable code. This duplicates the check applied for the access
level. Skip the exportability reports about non-public imports and keep
the more familiar access-level check.
Fix the note pointing to the import when using a package type in a
public declaration or inlinable code. We want a note on the import only
when it actually lowers the access level of the imported decl.
The note about a `package import` was simply be superfluous, while the
same note about a `public import` would trigger an assert later on.
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.
Previously, implicit imports were also being added to the module interface during override checking (without any diagnostic).
Additionally, correct the structure of the import which contained an extra, duplicated path component. It would be diagnosed as a scoped import and written into the interface like this:
```
import UIKit/*.UIKit*/
```
Resolves rdar://104935794
Using an access-level on an import downgrades imported decl from public
to the import's access-level. When we can identify which decl is
problematic, name it in the note displayed on the import. This should
help understanding the effect of the import's access level on the decl
causing an error further down in the source file.
Inlinable code can only refer to public types, so either local public
types or public types imported publicly. Report any decl imported as
non-public in inlinable code.
rdar://105902141
The following diagnostic is meant to prevent broken swiftinterfaces from being emitted:
```
'SomeAlias' aliases 'SomeDesugaredType' and cannot be used here because 'DesugaredTypeModule' was not imported by this file; this is an error in Swift 6
```
If the module exporting the reference to the typealias is non-resilient, though, then the module is not expected to have a buildable `swiftinterface` and therefore the diagnostic is superfluous.
Resolves rdar://104749045
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Until Swift 6, always downgrade to a warning the diagnostic on the use
in API of a conformance that wasn't imported by the local source file.
rdar://98851314
Implicitly imported decls may end up in inlinable code and break the
module API. This have been known to lead to deserialization crash and
could in theory break the generated swiftinterfaces files. Let's
explicitly check for such a case, keeping it to a warning until Swift 6
where we can make it an error.
rdar://95816286
In apple/swift#41054, we fixed an oversight which caused us to not notice when a user erased a concrete type to an existential using an unavailable conformance. Unfortunately, this is source-breaking and needs to be reduced to a warning in Swift 5 mode unless the user opts in.
Fixes rdar://91940820.
