Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
Given an explicitly-nonisolated type such as
nonisolated struct S { }
all extensions of S were also being treated as nonisolated. This meant
that being implicitly nonisolated (i.e., when you're using nonisolated
default isolation) was different from explicitly-writing nonisolated,
which is unfortunate and confusing. Align the rules, such that an
extension of S will get default isolation:
extension S {
func f() { } // @MainActor if we're in main actor default isolation
}
Controlled from Swift with '-version-independent-apinotes', which, for the underlying Clang invocation enables '-fswift-version-independent-apinotes', results in PCMs which aggregate all versioned APINotes wrapped in a 'SwiftVersionedAttr', with the intent to have the client pick and apply only those that match its current Swift version, discarding the rest.
This change introduces the configuration flags for this mode as well as the corresponding logic at the beginning of `importDeclImpl` to canonicalize versioned attributes, i.e. select the appropriate attributes for the current target and discard the rest.
Previously this flag was only used to pass explicit dependencies to compilation tasks. This change adds support for the dependency scanner to also consider these inputs when resolving dependencies.
Resolves https://github.com/swiftlang/swift-driver/issues/1951
We sometimes don't have the information in the modulemaps whether a
module requires ObjC or not. This info is useful for reverse interop.
This PR introduces a frontend flag to have a comma separated list of
modules that we should import as if they had "requires ObjC" in their
modulemaps.
Since LayoutPrespecialization has been enabled by default in all compiler
invocations for quite some time, it doesn't make sense for it to be treated as
experimental feature. Make it a baseline feature and remove all the
checks for it from the compiler.
Most of the logic for C++ foreign reference types can be applied to C types as well. Swift had a compiler flag `-Xfrontend -experimental-c-foreign-reference-types` for awhile now which enables foreign reference types without having to enable C++ interop. This change makes it the default behavior.
Since we don't expect anyone to pass `experimental-c-foreign-reference-types` currently, this also removes the frontend flag.
rdar://150308819
The concrete nesting limit, which defaults to 30, catches
things like A == G<A>. However, with something like
A == (A, A), you end up with an exponential problem size
before you hit the limit.
Add two new limits.
The first is the total size of the concrete type, counting
all leaves, which defaults to 4000. It can be set with the
-requirement-machine-max-concrete-size= frontend flag.
The second avoids an assertion in addTypeDifference() which
can be hit if a certain counter overflows before any other
limit is breached. This also defaults to 4000 and can be set
with the -requirement-machine-max-type-differences= frontend flag.
This was used a long time ago for a design of a scanner which could rely on the client to specify that some modules *will be* present at a given location but are not yet during the scan. We have long ago determined that the scanner must have all modules available to it at the time of scan for soundness. This code has been stale for a couple of years and it is time to simplify things a bit by deleting it.
When building against the static standard library, we should define
`SWIFT_STATIC_STDLIB` to indicate to the shims that the declarations
should be giving hidden visibility and default DLL storage. This is
required to ensure that these symbols are known to be `dso_local` when
compiling to avoid an unnecessary look up through the PLT/GOT or the
indirection through the synthesized `__imp_` symbol and the IAT. This
corrects a number of incorrect code generation cases on Windows with the
static standard library.
Create a path that swift-frontend can execute an uncached job from
modules built with CAS based explicit module build. The new flag
-import-module-from-cas will allow an uncached build to load module
from CAS, and combined with source file from real file system to build
the current module. This allows quick iterations that bypasses CAS,
without full dependency scanning every time in between.
rdar://152441866
The LeastValidPointerValue is hard-coded in the runtime.
Therefore this option is only available in embedded swift - which doesn't have a runtime.
rdar://151755654
Textual interfaces for 'Darwin' built with recent compilers specify that it is built witout C++ interop enabled. However, to ensure compatibility with versions of the 'Darwin' module built with older compilers, we hard-code this fact. This is required to break the module cycle that occurs when building the 'Darwin' module with C++ interop enabled, where the underlying 'Darwin' clang module depends on C++ standard library for which the compiler brings in the 'CxxStdlib' Swift overlay, which depends on 'Darwin'.
This feature is essentially self-migrating, but fit it into the
migration flow by marking it as migratable, adding
`-strict-memory-safety:migrate`, and introducing a test.
The following warnings get emitted every time we build the compiler libraries
that are implemented in Swift:
```
<unknown>:0: warning: ignoring -allow-non-resilient-access (overriden by -compile-module-from-interface or -typecheck-module-from-interface)
<unknown>:0: warning: ignoring -package-cmo (requires -allow-non-resilient-access)
<unknown>:0: warning: ignoring -allow-non-resilient-access (overriden by -compile-module-from-interface or -typecheck-module-from-interface)
<unknown>:0: warning: ignoring -package-cmo (requires -allow-non-resilient-access)
```
These warnings are generated because `-allow-non-resilient-access` and
`-package-cmo` are being passed in with `-Xfrontend` and are therefore copied
into the interface verification jobs, even though they don't apply. Suppress
the warnings under these circumstances; they aren't going to help anyone
understand a problem, so they're just spam.
Resolves rdar://151616909.
Using IncludeTree::FileList to concat the include tree file systems that
are passed on the command-line. This significantly reduce the
command-line size, and also makes the cache key computation a lot
faster.
rdar://148752988
-nostdimport and -nostdlibimport only remove the toolchain and usr/lib/swift search paths, and they leave the framework search paths intact. That makes it impossible to get a fully custom SDK environment. Make their behavior match clang's -nostdinc/-nostdlibinc behavior: treat framework and non-framework paths the same. In other words, -nostdinc removes *all* compiler provided search paths, and -nostdlibinc removes *all* SDK search paths.
Rename SkipRuntimeLibraryImportPaths to SkipAllImportPaths, and ExcludeSDKPathsFromRuntimeLibraryImportPaths to SkipSDKImportPaths to reflect their updated behavior.
Move the DarwinImplicitFrameworkSearchPaths handling from SearchPathOptions to CompilerInvocation, where RuntimeLibraryImportPaths is managed. Rename it to just ImplicitFrameworkSearchPaths, and filter for Darwin when it's set up so that all of the clients don't have to do Darwin filtering themselves later.
rdar://150557632
With `ARCMigrate` and `arcmt-test` removed from clang in
https://github.com/llvm/llvm-project/pull/119269 and the new code
migration experience under way (see
https://github.com/swiftlang/swift-evolution/pull/2673), these options
are no longer relevant nor known to be in use. They were introduced
long ago to support fix-it application in Xcode.
For now, turn them into a no-op and emit a obsoletion warning.
It has indirect effects on the accessors, so it shouldn’t matter, but we can defensively redirect the query to the API counterpart anyway.
This was the last `InferredInABIAttr` attribute, so we can now remove all of the infrastructure involved in supporting attribute inference.
