Upstream LLVM in llvm/llvm-project#139584 changed `DiagnosticOptions`
from being a referenced counted object to just be a reference, not owned
by the `clang::DiagnosticEngine`.
In 0981b71090 (part of #82243), the usages
of the Swift repository were adapted to the new memory model, but it
introduced at least one use-after-free and a potential one around the
usage of Clang in the Clang Importer.
This commit tries to fix the use-after-free in both cases, by returning
a `unique_ptr` to the `clang::DiagnosticOptions`, which makes the
lifetime of the `DiagnosticOptions` match the lifetime of the variable
that uses it (normally a `CompilerInvocation`).
Other cases in 0981b71090 should be safe
because the lifetime of the `DiagnosticOptions` do not seem to propagate
beyond the scope of the functions where they live (but I am not fully
sure about the one in `IDETool/CompilerInvocation.cpp` completely).
This was causing compiler crashes during the test
`Interop/Cxx/stdlib/unsupported-stdlib.swift` which eventually uses
`createClangDriver` and tries to emit a diagnostic, which in some cases
was reading the memory from `DiagnosticOptions` when it was already out
of scope.
[cxx-interop] Make ClangDeclExplicitSafety request non-recursive
[cxx-interop] Do not import template type arguments
[cxx-interop] Check template argument safety in ClangDeclExplicitSafety
Doing so reduces opportunities for caching, but it's not obvious to me
that we benefit from such fine-grained caching. The benefit here is that
we also avoid the pitfalls of incremental caching, as illustrated by the
added test case. Finally, we eliminate the use of hasActiveRequest(),
which is an anti-pattern.
The search paths for apinotes are leaked when using compilation caching
but they are not needed like other search path because the apinotes are
found and stored inside include-tree.
rdar://164205657
Checking this upon import may overlook annotations that explicitly
mark a type as safe (or unsafe). Instead, we consolidate this logic in
the ClangDeclExplicitSafety request.
rdar://163196609
This change just stages in a few new platform kinds, without fully adding
support for them yet.
- The `Swift` platform represents availability of the Swift runtime across all
platforms that support an ABI stable Swift runtime (see the pitch at
https://forums.swift.org/t/pitch-swift-runtime-availability/82742).
- The `anyAppleOS` platform is an experimental platform that represents all of
Apple's operating systems. This is intended to simplify writing availability
for Apple's platforms by taking advantage of the new unified OS versioning
system announced at WWDC 2025.
- The `DriverKit` platform corresponds to Apple DriverKit which is already
supported by LLVM.
Lookups like Builtin::Int64 were failing because BuiltinUnit rejected all unqualified lookups. Make it allow unqualified lookups with a module selector.
Checking this upon import was overlooking annotations that explicitly
mark a type as safe (or unsafe). Instead, we consolidate this logic in
the ClangDeclExplicitSafety request.
rdar://163196609
Any safe wrapper expansion originating in a bridging header would fail
typechecking because the `__ObjC` module doesn't import the standard
implicit imports. This is because the main module is not available to
inherit implicit imports from when the `__ObjC` module is created. We
don't need all of the implicit modules for safe wrappers, so import
`Swift` specifically.
rdar://163078116
hasDestroyTypeOperations() does not account for the scenario where
decl has an implicit destructor that has not yet been materialized
(i.e., using clang::Sema::{Declare,Define}ImplicitDestructor()).
This can sometimes happen to a type Foo if we check the value semantics
of, say, std::vector<Foo> (which recursively checks the value semantics
of Foo without first importing Foo).
rdar://162539654
The explicit safety analysis inadvertently considered every instance
method with this annotation unsafe. We trust these annotations, so let's
not consider the annotated methods unsafe.
rdar://162602614
Imports of modules marked `requires: cplusplus` should only be inherited
when C++ interop is enabled. Similarly, imports of modules marked
`requires: !cplusplus` should only be inherited when C++ interop is
disabled.
Inheriting a clang import marked `requires: !swift` will always result
in an error. This skips such imports, which *may* result in name lookup
errors instead, but also may not, depending on the module.
rdar://161795145
Doing so preserves ClangImporter's behavior first introduced in
f12b48aa86, but do so without relying on
importing the type argument (since that can lead to template
over-instantiation).
This patch also promotes the logic of hasUnsafeType() to a standalone
SimpleRequest, to provide a QualType-typed entry point for evaluating
the safety of a Clang entity.
When importing C++ class template specializations into Swift, we were assigning the owning module to the imported Swift structs inconsistently. For specializations that had a typedef (or a using-decl), we assumed the module that declares the typedef to be the owning module for the specialization. For specializations that do not have a typedef, we assumed the module that declares the class template itself to be the owning module. This changes the behavior to always assume the latter.
rdar://158589803
When expanding a Swift macro in a clang module where the original clang
module imported a submodule in a C++ standard library module other than
`std`, e.g. a submodule to `std_core`, this would result in an error.
This is because `std_core.math.abs` would be imported as
`CxxStdlib.math.abs`, which would later be translated back as
`std.math.abs` which doesn’t exist.
This changes the mapping to only map `std` to `CxxStdlib`. To prevent
errors when importing modules starting with `std_`, this error is moved
from the late-stage module import to the earlier processing of
`ImportDecl`s. This results in these module names still being forbidden
in explicit imports (i.e. naming them in source code), while still being
allowed in implicit imports inherited from clang modules.
This also fixes a fix-it bug where only the first 3 characters would be
selected for replacing with `CxxStdlib` when importing `std_core`.
This also fixes a diagnostic bug where aliased modules would refer to
the module name in the source code rather than the real module name, and
adds a note clarifying the situation.
rdar://161795429
rdar://161795673
rdar://161795793
fix non-fatal import error
Introduce CustomAttrOwner that can store either a Decl for an
attached attribute, or a DeclContext for e.g a type or closure
attribute. Store this on CustomAttr such that we can query it from
the name lookup requests.
The overload resolution generated a constraint that tried to bind
outer.inline_inner to outer. This constraint failed. This PR attempts to
recognize this scenario and make the constraint succeed.
rdar://158401346
We were not handling nullptrs consistently. This shouldn't actually
change the behavior for any known case but makes the error handling
logic a little more explicit and robust.
