The diagnostic pass that checks whether expressions reference member
declarations that have not been imported failed to handle key path expressions.
Resolves rdar://159093481.
The migration to `MemberImportVisibility` can be performed mechanically by
adding missing import declarations, so offer automatic migration for the
feature.
Resolves rdar://151931597.
The was never invoked because inaccessibility due to SPI protection level is
always diagnosed before missing imports are diagnosed. The functionality could
therefore not be tested and should be removed.
Omit an explicit access level from `MemberImportVisibility` fix-its under the
following conditions:
- `InternalImportsByDefault` is enabled.
- The required import needs an `internal` access level or lower.
- The module is not yet imported explicitly in any other file.
Resolves rdar://149577615.
Unlike in Swift, Obj-C allows method overrides to be declared in extensions
(categories), even outside of the module that defines the type that is being
extended. When MemberImportVisibility is enabled, these overrides must be
filtered out to prevent them from hijacking name lookup and causing the
compiler to insist that the module that defines the extension be imported.
Resolves rdar://145329988.
Unlike in Swift, Obj-C allows method overrides to be declared in extensions
(categories), even outside of the module that defines the type that is being
extended. When MemberImportVisibility is enabled, these overrides must be
filtered out to prevent them from hijacking name lookup and causing the
compiler to insist that the module that defines the extension be imported.
Resolves rdar://145329988.
Expand the special-cased ASTWalker behavior for folded SequenceExprs
such that we always walk the folded expression when available. This
ensures that we don't attempt to add the same node multiple times
when expanding ASTScopes during pre-checking.
rdar://147751795
`recordObjCOverride()` records semantic overrides for imported Obj-C methods.
Since these methods are imported from a different language, it doesn't make
sense to enforce Swift's member import visibility rules when performing lookups
to find overridden methods. Doing so caused the Constrain Solver to lack
important information needed to eliminate overloads, resulting in erroneous
ambiguities.
Resolves rdar://141636723.
Adjust the valid position checking and special handle EOF position.
If the requested location is at EOF, use the last token, but still
emit the diagnostics at the specificied location.
rdar://138426038
Find all the usages of `--enable-experimental-feature` or
`--enable-upcoming-feature` in the tests and replace some of the
`REQUIRES: asserts` to use `REQUIRES: swift-feature-Foo` instead, which
should correctly apply to depending on the asserts/noasserts mode of the
toolchain for each feature.
Remove some comments that talked about enabling asserts since they don't
apply anymore (but I might had miss some).
All this was done with an automated script, so some formatting weirdness
might happen, but I hope I fixed most of those.
There might be some tests that were `REQUIRES: asserts` that might run
in `noasserts` toolchains now. This will normally be because their
feature went from experimental to upcoming/base and the tests were not
updated.
Create some test cases that demonstrate MemberImportVisibility behavior with respect referencing inherited members. There are already tests that demonstrate overrides, but nothing seemed to show the behavior when referencing an inherted member through a derived type. I wanted to verify this behavior so I wrote a test to demonstrate it. It seems reasonable to check-in the test to ensure the behavior remains consistent.
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.
If `OverriddenDeclsRequest` fails to find any overridden declarations, query
again ignoring missing imports to find declarations that were excluded due to the
`MemberImportVisibility` feature being enabled.
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.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
To improve knock-on diagnostics, resolve qualified types to their matching
member type declarations regardless of whether an import is missing when the
`MemberImportVisibility` features is enabled.
Part of rdar://126637855.
To improve knock-on diagnostics, resolve unqualified types to their matching
member type declarations regardless of whether an import is missing when the
`MemberImportVisibility` features is enabled.
Part of rdar://126637855.
When emitting fix-its for missing imports, include an access level when the
module has been imported with an access level in other source files. For now,
the suggested access level for will always be `internal`, even when uses of
members in the file would actually require `public` or `package` visibility. In
order to suggest the correct access level, name lookup will need to be
refactored to repair references to inaccessible declarations, instead of
leaving error nodes in the AST. In anticipation of that refactoring of name
lookup, missing import diagnostics are now delayed until type checking a source
file is finished so that a consistent access level can be suggested for each
import fix-it for a given module.
Partially resolves rdar://126637855.
In existing Swift, an `@_exported import` in any source file makes the
declarations from the imported module visible in all source files. It's unclear
whether this is an explicit decision or is simply and unintended consequence of
effectively adding an implicit import to each source file for the module being
compiled.
Although it's not clear whether this behavior is desirable, the behavior of
member lookup when the MemberImportVisibility feature is enabled should align
with it in order to avoid causing unnecessary churn in required imports.
Resolves rdar://132525152.
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.
In Swift 5.10 if you wrote `extension Foo {}` for some protocol Foo,
the extension would always re-use the generic signature of Foo, which
is <Self where Self: Foo>. In Swift 6 this no longer works because Foo
might be ~Copyable, in which case `extension Foo {}` adds default
requirements, so we changed GenericSignatureRequest to just always
build a new signature if we're given an extension.
However, to avoid a request cycle with a code example that really should
have never worked at all, I'm re-introducing the hack for re-using the
signature.
Fixes rdar://problem/129540617.
