The availability macros definitions are parsed from the command line and
stored in a cache. The cache was in the Parser, which would have it be
computed for each file using availability macros. Let's move it to the
ASTContext instead where it can generally be computed once per invocation
and used across the module.
rdar://134797088
Since this function is being called from the constraint solver now, we
need to generalize the way it obtains the Type of an Expression, as the
expression itself may not know its own type, only the solver does.
resolves rdar://134371893 / https://github.com/swiftlang/swift/issues/75999
The `TypeRefinementContextBuilder` could visit a given `VarDecl` in the AST
multiple times when the `VarDecl` has a parent `PatternBindingDecl`, resulting
in duplicate TRC nodes.
Nodes in the TypeRefinementContext tree should be introduced for enum cases,
rather than enum elements, since its the cases that carry availability
annotations. Previously, enum cases in source that contained more than one
element would result in a malformed TRC tree that had overlapping sibling nodes
for each of the elements in a case declaration.
If left-hand side of any conversion constraint is `inout` type
and right is a pointer (or optional thereof), delay simplification
until `inout` is at least partially structurally resolved (cannot
be a type variable or dependent member) because eager simplification
won't record all of the possible conversions.
Marking an observer unavailable (or potentially unavailable) has no effect
since the compiler emits calls to them unconditionally.
Resolves rdar://80337141.
When onlyIfImported is true, we should return the public module name
only when the public facing module is already imported. Replace the
call to getModuleByIdentifier with getLoadedModule to prevent trigering
loading that module.
Also fix the test where the CHECK lined ended up matching itself from
the diagnostics output.
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`.
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.
- 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.
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
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
