Update the logic selecting the most restrictive import for a given
reference to account for @_exported imports from the local module. We
should always prioritize @_exported imports from the local module over
more restrictive same file imports. Only if an import from the same file
is also public we prefer it as it's more useful for diagnostics and
generally recommended to locally declare dependencies.
Also update the test that was meant to check this configuration to apply
two different variations, one for a module local @_exported and one
relying on the underlying clang module.
rdar://140924031
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.
We may want to add a similar logic from getImportAccessLevel where
we determine the defining module in `diagnoseAndFixMissingImportForMember`.
It should recommend to add the authoritative import, without
considering those already present in the file. Then we can
delete the `registerRequiredAccessLevelForModule(definingModule, accessLevel);`
in `recordRequiredImportAccessLevelForDecl` and point to more
superfluous public imports.
Change how we pick the one import to point to in diagnostics about a
referenced decl. This mostly affects the warning about superfluously
public imports. This warning encourages the developer to delete imports,
let's make sure we push them towards deleting the right ones.
The order was previously not well defined, except that we always picked
one of the most public imports.
We now prioritize imports in this order:
1. The most public import. (Preserving the current behavior in
type-checking of access-level on imports)
2. The import of the public version of the module defining the decl,
determined via export_as or -public-module-name.
3. The import of the module defining the decl.
4. The first import in the sources bringing the decl via reexports.
5. Any other import, usually via an @_exported import in a different file.
rdar://135357155
