When macros like _SwiftifyImport are added to a wrapper module for a
clang module, they may need to refer to symbols declared in another
clang module that the wrapped module imports (e.g. because they are used
in the original signature). This adds all the imported clang modules as
implicit imports to the wrapper module.
rdar://151611573
Lookup into C++ namespaces uses a different path from C++ record declarations.
Augment the C++ namespace lookup path to also account for the auxiliary
declarations introduced by peer macro expansions.
Introduce a number of fixes to allow us to fully use declarations that
are produced by applying a peer macro to an imported declarations.
These changes include:
* Ensuring that we have the right set of imports in the source file
containing the macro expansion, because it depends only on the module
it comes from
* Ensuring that name lookup looks in that file even when the
DeclContext hierarchy doesn't contain the source file (because it's
based on the Clang module structure)
Expand testing to be sure that we're getting the right calls,
diagnostics, and generated IR symbols.
C++ swift::Parser is going to be replaced with SwiftParser+ASTGen.
Direct dependencies to it should be removed. Before that, remove
unnecessary '#include "swift/Parse/Parser.h"' to clarify what actually
depends on 'swift::Parser'.
Split 'swift::parseDeclName()' et al. into the dedicated files.
The `_Concurrency` module imports a C module that is not available in the
toolchain or SDK, which means that `@_implementationOnly` must be used to hide
the dependency on this module from clients.
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
Add support for access-level on imports and `@_spiOnly imports` to cross
import overlays. The overlay inherits the most restrictive import
access-level of the declaring module and the bystander module.
rdar://129606112
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)
Silence errors on ambiguous implicitly public imports when a different import
is explicitly public. In this case all imports are public so the ambiguity is
not dangerous and this configuration can happen during adoption of
access-levels on imports. Keep the error when an explicit import is package,
internal or below.
rdar://129037503
Adoption InternalImportsByDefault provides a safe access-level by default
to imports, as such ambiguities are not a risk and showing this warning is
superflous. When this warning is shown, make sure we note this alternative.
Report uses of `@_implementationOnly` in resilient modules as deprecated.
With a fixit to replace it with `internal` or delete it when imports
are internal by default.
Uses of `@_implementationOnly` in non-resilient modules is already reported
as being unsafe.
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
By default package decls are treated as resilient, similar to public (non-frozen).
This PR adds support to allow direct access to package decls at use site if opted-in.
Requires the loaded module to be a binary module in the same package.
Resolves rdar://121626315
In Swift 5 mode, the compiler reports when two files import the same
module, where one file has a bare import and the other an access-level
import. This avoids unintentionally promoting the import to public when
preexisting code marked it otherwise.
Exempt a file generated by Xcode from this check as it's not user
modifiable.
In the future, we should identify such generated files properly. Either
with a new attribute or in the way they are passed to the compiler.
rdar://122032472
As recommended in feedback on https://github.com/apple/swift/pull/71302, cache
the underlying clang module after loading it in `ImportResolver`, rather than
filtering it out of the overall set of resolved imports. This is more efficient
and results in less duplicated code that must identify the underlying clang
module.
The correct use @_implementationOnly from a non-resilient module is not
enforced by the compiler at this time. Using that configuration can
cause memory corruption at runtime if it affects the memory layout of
types, and it can lead to compiler crashes at compilation in general.
Some modules rely on this configuration with a very limited use for it.
We can grandfather them in its use and silence the warning on specific
import edges.
Warn on imports of the same target module from the same source file when
they have different access-levels. This situation can lead to unexpected
behavior as the compiler will only take into account the most permissive
import.
In the following example, the module Foundation in functionally imported
as public. The `internal` modifier will be ignored. The new diagnostic
reports it as such.
```
public import Foundation
internal import Foundation // warning: module 'Foundation' is imported
as 'public' from the same file; this 'internal' access level will be
ignored
```
This could be an easy mistake to do when using scoped imports where this
diagnostic will also help.
rdar://117855481
Add a new flag to enable package interface loading.
Use the last value of package-name in case of dupes.
Rename PrintInterfaceContentMode as InterfaceMode.
Update diagnostics.
Test package interface loading with various scenarios.
Test duplicate package-name.
This matches the current behavior in `ImportResolution`. The change refactors an existing utility function to do this check from `UnboundImport` to a common utility used now also in the scanner.
The compiler reports public imports of non-resilient modules from a
resilient module. Make sure that when imports default to internal, which
also implies Swift 6, this is treated as an error and the fixit simply
deletes the `public` keyword.
We keep using the AccessLevelOnImport flag only to report these as
errors in Swift 5 for early adopters.
Pointer `llvm/Support/Host.h` at `llvm/TargetParser/Host.h`.
Replacing deprecated API `startswith_insensitive` with replacement
`starts_with_insensitive`.
llvm::SmallSetVector changed semantics
(https://reviews.llvm.org/D152497) resulting in build failures in Swift.
The old semantics allowed usage of types that did not have an
`operator==` because `SmallDenseSet` uses `DenseSetInfo<T>::isEqual` to
determine equality. The new implementation switched to using
`std::find`, which internally uses `operator==`. This type is used
pretty frequently with `swift::Type`, which intentionally deletes
`operator==` as it is not the canonical type and therefore cannot be
compared in normal circumstances.
This patch adds a new type-alias to the Swift namespace that provides
the old semantic behavior for `SmallSetVector`. I've also gone through
and replaced usages of `llvm::SmallSetVector` with the
`Swift::SmallSetVector` in places where we're storing a type that
doesn't implement or explicitly deletes `operator==`. The changes to
`llvm::SmallSetVector` should improve compile-time performance, so I
left the `llvm::SmallSetVector` where possible.
@_implementationOnly was designed for use from resilient modules only,
using it from non-resilient modules in unsupported. This change adds a
warning about it.
If anyone hits this warning, they should either enable library-evolution
or consider adopting the new `internal import` when it is available as
it handles this scenario properly.
What leads to a crash: an @_implementationOnly import fully hides the
dependency from indirect clients. This can lead to the compiler being
unaware of some internal details of a non-resilient module when building
a client against it. In turn this may lead to run time crashes from
miscompilation.
In general one could still use @_implementationOnly in a non-resilient
modules as long as it's referenced only from function bodies. However,
references from even non-public properties does lead to important memory
layout information being hidden from clients of the module.
rdar://78129903
