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
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
This disallows building an interface file that imports such module which should be allowed
since interface does not contain package symbols unless usableFromInline or inlinable.
This change limits erroring only when building a .swift file.
Resolves rdar://108633068
When using the -testable-import-module argument to insert a testable
import, there's no ImportDecl on which to show the diagnostics when
loading transitive dependencies. Clean up the logic to still load
dependencies in such a case.
A @testable import allows a client to call internal decls which may
refer to non-public dependencies. To support such a use case, load
non-public transitive dependencies of a module when it's imported
@testable from the main module.
This replaces the previous behavior where we loaded those dependencies
for any modules built for testing. This was risky as we would load more
module for any debug build, opening the door to a different behavior
between debug and release builds. In contrast, applying this logic to
@testable clients will only change the behavior of test targets.
rdar://107329303
Importing a non-library-evolution enabled module from a
library-evolution enabled module will lead to generating a
swiftinterface that can't be rebuilt by a different compiler.
Make it a hard error when using access level imports, and keep it as a
warning for @_implementationOnly imports.
When targeting Swift 5 and earlier, the default import is public. To
notify of a possible unintentional public import, raise errors on
default imports when other imports of the same target have an explicit
type.
This check isn't necessary in the tentative Swift 6 mode.
`getValue` -> `value`
`getValueOr` -> `value_or`
`hasValue` -> `has_value`
`map` -> `transform`
The old API will be deprecated in the rebranch.
To avoid merge conflicts, use the new API already in the main branch.
rdar://102362022
Break findInconsistentImportsAcrossFile into two services, one finding
inconsistencies across a whole module and a new one finding them across
a single file.
The effect of declaring an import `@_weakLinked` is to treat every declaration from the module as if it were declared with `@_weakLinked`. This is useful in environments where entire modules may not be present at runtime. Although it is already possible to instruct the linker to weakly link an entire dylib, a Swift attribute provides a way to declare intent in source code and also opens the door to diagnostics and other compiler behaviors that depend on knowing that all the module's symbols will be weakly linked.
rdar://96098097
Introduce the `@preconcurrency` attribute name for `@_predatesConcurrency`,
which has been the favored name in the pitch thread so far. Retain the
old name for now to help smooth migration.
The change to add the `import` keyword location to AttributedImport also
removed the module name location in UnboundImport. However, we want to
keep both locations, for different diagnostic reasons, so reinstate the
module name location.
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
