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.
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.
`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.
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.
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.
In rdar://123649082, a project failed to build because of the lazy import-as-member loading changes in #71320. That project was configured in a way that broke modularization and the correct solution is to fix it, but out of an abundance of caution, add a `-disable-named-lazy-import-as-member-loading` frontend flag in case a project needs to temporarily restore the old behavior.
As a bonus, this lets us write a test to verify that lazy import-as-member loading has positive performance impact.
If an extension isn't imported either directly or via a transitive
(`@_exported`) import, its members should not be visible to name
lookup. Implement this behavior behind the experimental flag
ExtensionImportVisibility.
The review of SE-0395 is down to small details at this point that won't
affect the overall shape of the API much. Rename the model in
anticipation of that.
Check accessibility of all build{Partial}Block overloads and
diagnose if none of them are as accessible as type, otherwise
swift interfaces could end up with invalid result builder
declarations when type is public and all builder methods are
internal.
Resolves: rdar://104384604
"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
Private imports are intended to make the file performing the import more or less source-compatible with the file being imported from, so that code from the original file can be modified by relatively simple syntactic transformations. However, their name shadowing behavior was very different from the original file. In the original file, other declarations in the same module would have shadowed declarations imported from any other module; in a file using a @_private import, they would all be considered imports, and thus all would be preferred equally. This could cause ambiguity in a file using a @_private import that was not present in the original file.
This commit changes that behavior by favoring @_private imports over other imports, so that if a name is visible through both a private and a non-private import, the one visible through the private import will shadow the other. This shadowing takes a higher priority than a scoped import, but a lower priority than the check for whether one of the modules is only visible through the other.
Fixes rdar://68312053.
Move reference dependency tests out of NameLookup and into
Incremental/Dependencies. These tests will need to be specialized for
the upcoming private dependencies code.
The directory currently seems to have a mix of
tests for import resolution and name lookup.
Therefore split it into two directories;
ImportResolution and NameLookup.
