-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
Previously we would insert StringRefs that reference the keys in the
map, but that breaks if the invocation ever gets copied. Switch to
`std::string`.
rdar://148130166
In expectation, this should never happen. Such a situation means that within the same scanning action, Clang Dependency Scanner has produced two different variants of the same module. This is not supposed to happen, but we are currently hunting down the rare cases where it does, seemingly due to differences in Clang Scanner direct by-name queries and transitive header lookup queries.
This hash is also used for the dependency scanning hash. In both cases, PCH contents may differ based on whether a certain module they depend on is found in a system or non-system search path. In dependency scanning, systemness should cause a full change of scanning context requiring a from-scratch scan.
Resolves rdar://150334077
Swift started to explicitly forbid the instantiation of C++ function
templates with arbitrary types in #77430, because many types cause the
Swift compiler to crash. However, those checks prevented them from being
instantiated with Swift closures (which were previously fine), causing
a regression.
This patch relaxes the convertTemplateArgument() function to also allow
converting Swift function types, and adds some tests to make sure doing
so is fine.
This patch also does some cleanup of existing tests checking the
instantiation of various types, and adds testing for C function pointers
and Obj-C blocks.
rdar://148124104
(cherry picked from commit 284de98744)
When determining whether a nested type is safe, don't consider whether
its enclosing type is safe. They're independent.
(cherry picked from commit 8ec52c825c)
When serializing `@available` attributes, if the attribute applies to a custom
domain include enough information to deserialize the reference to that domain.
Resolves rdar://138441265.
Suppose module 'Foo' exists in the search paths and specifies user module version '1.0'.
If the first encountered 'canImport' query is unversioned:
...
Followed by a versioned one:
...
The success of the first check will record an unversioned successful canImport, which will cause the second check to evaluate to 'true', which is incorrect.
This change causes even unversioned 'canImport' checks to track and record the discovered user module version.
Specifically, when the scanner found a candidate which does not carry a user-specified version, it will pass '-module-can-import Foo' to compilation. During compilation, if the check is versioned but the candidate is unversioned, evaluate the check to 'true' to restore the behavior we had with implicitly-built modules.
Resolves rdar://148134993
The builtin’s current is signature is:
```
(Any.Type, Any.Type) -> Bool
```
This needs to be changed to this:
```
(any (~Copyable & ~Escapable).Type, any (~Copyable & ~Escapable).Type) -> Bool
```
This requires a bit of support work in AST synthesis.
rdar://145707064
Co-authored-by: Alejandro Alonso <alejandro_alonso@apple.com>
An "abstract" ProtocolConformanceRef is a conformance of a type
parameter or archetype to a given protocol. Previously, we would only
store the protocol requirement itself---but not track the actual
conforming type, requiring clients of ProtocolConformanceRef to keep
track of this information separately.
Record the conforming type as part of an abstract ProtocolConformanceRef,
so that clients will be able to recover it later. This is handled by a uniqued
AbstractConformance structure, so that ProtocolConformanceRef itself stays one
pointer.
There remain a small number of places where we create an abstract
ProtocolConformanceRef with a null type. We'll want to chip away at
those and establish some stronger invariants on the abstract conformance
in the future.
* [CS] Decline to handle InlineArray in shrink
Previously we would try the contextual type `(<int>, <element>)`,
which is wrong. Given we want to eliminate shrink, let's just bail.
* [Sema] Sink `ValueMatchVisitor` into `applyUnboundGenericArguments`
Make sure it's called for sugar code paths too. Also let's just always
run it since it should be a pretty cheap check.
* [Sema] Diagnose passing integer to non-integer type parameter
This was previously missed, though would have been diagnosed later
as a requirement failure.
* [Parse] Split up `canParseType`
While here, address the FIXME in `canParseTypeSimpleOrComposition`
and only check to see if we can parse a type-simple, including
`each`, `some`, and `any` for better recovery.
* Introduce type sugar for InlineArray
Parse e.g `[3 x Int]` as type sugar for InlineArray. Gated behind
an experimental feature flag for now.
https://github.com/swiftlang/swift/pull/79807 caused a regression in which
`AvailabilityContext` stopped tracking the available version range for the
active platform domain for certain platforms. Fix this by reverting to checking
`AvailabilityDomain::isActive()` to determine when a given platform
`AvailabilityDomain` represents the target platform. The compiler's existing
mapping from target triple to platform domain is incomplete and it's not clear
to me whether fixing that could cause other regressions.
Resolves rdar://147413616.
Switch over to split caching for the conformance isolation request,
which optimizes for the common case where the conformance is
nonisolated. Also put the explicit global actor TypeExpr* in an
ASTContext side table, so we don't take a pointer's worth of storage
in every conformance.
For that side table, introduce a new "ASTContext::GlobalCache" that's
there only for side tables, so we don't have to go add get/set
operations to ASTContext and recompile the world every time we want to
add a side table like this.
Thanks, Slava!
Added an `-executor-factory` argument to the compiler to let you safely
specify the executors you wish to use (by naming a type that returns
them).
Also added some tests of the new functionality.
rdar://141348916
Store `CustomAvailabilityDomain` instances in a folding set on `ASTContext`.
This instances of custom domains to be created without needing to cache them in
disparate locations.
For build systems that already generate these files, it makes sense to include the aliases so that the map file serves as a comprehensive index of how the module inputs are referenced.
Normal conformances, self conformances, and availability contexts cannot
contain types with type variables, so there is no reason to duplicate
the uniquing maps between the permanent arena and solver arena.
This makes more efficient use of the permanent memory allocated for
`AvailabilityContext` representations and also fixes a leak that was introduced
in https://github.com/swiftlang/swift/pull/79718 where the small vector for
unavailable domain storage was not being cleaned up on `ASTContext`
deallocation.
Resolves rdar://145929932.
* Move `AvailabilitySpec` handling logic to AST, so they can be shared
between libParse and ASTGen
* Requestify '-define-availability' arguments parsing and parse them
with 'SwiftParser' according to the 'ParserASTGen' feature flag
* Implement 'AvailableAttr' generation in ASTGen
When Swift passes search paths to clang, it does so directly into the HeaderSearch. That means that those paths get ordered inconsistently compared to the equivalent clang flag, and causes inconsistencies when building clang modules with clang and with Swift. Instead of touching the HeaderSearch directly, pass Swift search paths as driver flags, just do them after the -Xcc ones.
Swift doesn't have a way to pass a search path to clang as -isystem, only as -I which usually isn't the right flag. Add an -Isystem Swift flag so that those paths can be passed to clang as -isystem.
rdar://93951328
Protocol conformances have a handful attributes that can apply to them
directly, including @unchecked (for Sendable), @preconcurrency, and
@retroactive. Generalize this into an option set that we carry around,
so it's a bit easier to add them, as well as reworking the
serialization logic to deal with an arbitrary number of such options.
Use this generality to add support for @unsafe conformances, which are
needed when unsafe witnesses are used to conform to safe requirements.
Implement general support for @unsafe conformances, including
producing a single diagnostic per missing @unsafe that provides a
Fix-It and collects together all of the unsafe witnesses as notes.
