This PR adjusts the documentation for `Mutex.withLockIfAvailable()` to clarify
that it is not subject to spurious failures. The C11 and C++11 specs for their
respective `tryLock()` APIs allow for spurious failures, but our implementations
and those of every other similar API I've found don't use weak `cmpxchg`s and
don't spuriously fail.
Feedback in #85445 after it merged pointed out that the changes around
`createClangInvocation` are not necessary because `CompilerInvocation`
do not hold a reference to `clang::DiagnosticOptions`, only the
`clang::driver::Driver` does.
These changes undo the modifications done there and return the code to
the previous state (but keeps the changes around `createClangDriver`
which was causing the use-after-free).
Explicit module builds currently fail on Windows because
direct-clang-cc1-module-build emit-pcm commands take overlaid system
module map files as inputs but miss the clang VFS overlay. This change
adds the overlay and fixes explicit module builds on Windows.
When performing multi-threaded IRGen, all of the link libraries used
for autolinking went (only) into the first object file. If the object
files were then placed in a static archive, the autolinking would only
kick in if clients that link the static library reference something in
the first object file. This causes link failures.
Make sure that we put the autolink information into each of the object
files we create when doing multi-threaded IRGen.
Fixes the rest of rdar://162400654.
The existing check is no-op because it would never produce a null for
`paramType` under the conditions in `else` branch. A better
API it use here is `conformsToKnownProtocol` just like in other cases.
Ensure that calls to SPI operators are only accepted in source files
importing the corresponding SPI group. This applies the same logic to
operators as we do for functions.
rdar://137713966
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.
This makes sure that whenever we emit `#if defined(__OBJC__)`, the matching `#endif` has a comment `// defined(__OBJC__)`.
This makes both testing and reading the header file easier.
On all platforms except Linux, calling `withLockIfAvailable()`
recursively just returns `nil`. However, our Linux implementation
chooses to abort the process instead. We don't need this
inconsistent/destructive behaviour and can just return `nil` as we do
elsewhere.
Teach SIL type lowering to recursively track custom vs. default deinit status.
Determine whether each type recursively only has default deinitialization. This
includes any recursive deinitializers that may be invoked by releasing a
reference held by this type.
If a type only has default deinitialization, then the deinitializer cannot
have any semantically-visible side effects. It cannot write to any memory
On macOS 26, malloc_zone_statistics() always returns
a malloc_statistics_t with the max_size_in_use field
set to zero. This was an intentional change, so let's
remove calls to this API.
Instead, use the proc_pid_rusage() API and return the
ri_lifetime_max_phys_footprint field of rusage_info_v4.
Finally, remove the llvm::sys::Process::GetMallocUsage()
call on other platforms altogether. It returns the
current value and not the max value, so its misleading.
