**Overview**:
This PR introduces the basic infrastructure needed to eventually migrate
derived macros generation from hand-crafted AST nodes to macros. No
conformance have been migrated yet.
**Motivation**:
Derived conformances (e.g. `Equatable`, `Hashable`, `Codable`, ...) are
currently implemented as a special case in the compiler, producing
synthetic AST nodes directly. Migrating this to macros will hopefully
unify the code path with the existing macro expansion infrastructure,
make conformance synthesis easier to extend and test as well as reducing
the amount of special cases in the compiler.
**Changes**:
- New experimental feature flag `DeriveConformancesViaMacros`:
Introduces the flag that will eventually gate the new derived
conformance code paths. It does not control any behaviour for the moment
as none have been migrated yet but this enables future changes to be
built incrementally.
- New GeneratedSourceInfo and SourceFile kinds `SyntheticMacro`:
Introduces new GSI and SourceFile kinds named `SyntheticMacro` to
represent macros synthesized by the compiler. Since macros need a real
buffer to expand, this is the kind of source file and GSI associated
with those buffers.
- Conformance derivation via macros API:
Introduces the `deriveRequirementViaMacro` function that produces the
required witness via macro expansion.
See https://github.com/swiftlang/llvm-project/pull/13124 for
llvm-related changes.
**Next steps**:
- Macros do not contain any semantic information, especially regarding
types. Therefore it is necessary to provide them with type information
as an argument so they can eventually derive the conformances. A
separate PR is being created to generate this type information as
strings containing swift-parsable code for easy parsing on the macro
end.
- Implement derived conformance synthesis for individual protocols using
the new infrastructure, like `Equatable` or `Hashable` for starters.
- Wire the experimental flag to gate the new path once an implementation
exists
---------
Co-authored-by: Hamish Knight <hamish_knight@apple.com>
If our deployment target is a future release version (99.99+) then
we would end up returning the latest known release version, e.g.,
6.3. That seemed counter to the intention of
eac9b3cb58 and the description in
`findSwiftRuntimeVersion`, which says we should return
`std::nullopt` to indicate that we're not bound to any version.
This change adds support for raw identifiers when renaming APIs in
Swift. This includes APIs defined in Swift (using the
`@availability(..., renamed: ...)` attribute), as well as C/Objective-C
(using either the `swift_name` attribute or APINotes). All of these take
decl names as strings, and so the parsing for these requires that any
decl name components (the base name or the argument labels) must have
surrounding backticks in order to be treated correctly as a raw
identifier.
Getting this working required some refactoring of `ParsedDeclName`
since it previously assumed that it could just split around delimiters
like `.`, `(`, and `:`. That's no longer guaranteed to work, so I've
introduced backtick-aware split helpers to deal with this. Likewise,
`ParsedDeclName` now keeps track of special decl base names (like
`init` and `subscript`) to ensure that they're handled properly and
not incorrectly escaped under the new logic.
- **Explanation**: Adding support for `swift-frontend -print-target-info -target wasm32-unknown-emscripten`, which is required before this triple is supported in `swiftc`.
- **Scope**: Limited to Emscripten Wasm support.
- **Issues**: rdar://175887675
- **Risk**: Very low due to limited scope.
- **Testing**: Added a new case to the lit test suite.
In #88224 we moved to unversioned triples. However in using the existing
getUnversionedTriple implementation, we lost the call to
getMajorArchitectureName and just used getArchName on the triple.
On OpenBSD, the spelling is amd64. We make a number of transpositions to
use the LLVM spelling x86_64 in a number of places, but the target
triple by default uses amd64. This means that instead of having a
mismatch between versioned and unversioned triple, we have a mismatch
between architecture spellings.
Here, we call getMajorArchitectureName on OpenBSD to use the LLVM
architecture spellings in getUnversionedTriple for the platform. This is
only a problem for amd64/x86_64; there is no problem on aarch64,
which is why this wasn't spotted earlier.
Prior to this change, we used versioned triples on this platform.
However, swift-build and the planned future migrations effectively
constrain the platform to abandon this module naming scheme.
Ideally, we would look for a swiftmodule named after the versioned
triple, then fall back to the unversioned triple, or vice versa.
However, this is not straightforward to do, and/or would induce a larger
change. It transpired that it was more straightforward to just convert,
despite reservations and modules generated on earlier versions requiring
recompilation in the future. Because the install base for the platform
is likely few, tackle the work to implement the fallback later and just
get this quickly done first, especially so we can hopefully make the cut
to have this incorporated in 6.3.
As a complement to `@available(anyAppleOS ...)`, evaluate `#if os(anyAppleOS)`
to true when targeting Apple's operating systems.
Resolves rdar://172747814.
This no longer causes a regression in number of CAS instances.
Prefer llvm::cas::CASConfiguration where it used to clang::CASOption.
(cherry picked from commit 4f059033bb)
llvm::VersionTuple now also supports 5-component versions; this patch removes
the limitation of stripping the last component when converting from a
swift::version::Version to an llvm::VersionTuple. This fixes a bug in LLDB's
Swift version compatibility warning.
rdar://170181060
This complements the existing Time and Live columns which (a) measure process CPU time, not wall clock time and (b) only offer 25 microsecond level precision or worse on Windows.
Otherwise these source file objects linger in the source manager but they refer to a fully-temporary 'ASTContext' which does not exist after parsing is complete, which means they cannot be used in any way and attempting to do so would lead to a crash.
This removes the C++ interop compat version mechanism. It was added in mid-2023 and was never used. It complicates the testing story, and makes it harder to reason about the compiler's behavior. It also isn't compatible with explicit module builds.
The flag `-cxx-interoperability-mode` is preserved, so projects that use the flag will continue to build normally.
rdar://165919353
This reverts commit 4f059033bb. The change
is actually not NFC since previously, there is a cache in the
CompilerInvocation that prevents the same CAS from the same CASOptions
from being initialized multiple times, which was relied upon when
running inside sub invocation. When switching to a non-caching simple
CASOption types, it causes every single sub instance will create its own
CAS, and it can consume too many file descriptors and causing errors
during dependency scanning.
rdar://164903080
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.
The `Task` class was missing a destructor to close pipe file descriptors when
destroyed. This caused file descriptor exhaustion after ~2,187 test runs,
making tests fail with POLLNVAL errors when the system ran out of resources.
This was found with:
```
./unittests/Basic/SwiftBasicTests --gtest_filter="TaskQueueTest.*" --gtest_repeat=1000
```
On older x86_64 hardware, this isn't a problem since CET IBT hardware
support may not have been available. However, newer x86_64 hardware
supports the feature, which will lead to BTCFI failures. Therefore ensure
the same BTCFI disabling logic applies on x86_64 as well as aarch64.
Removed:
- unused `SizeStatEntry` struct and `SizeStats` vector
- unused statistics counters
- dead code from `printManglingStats()` that referenced these variables
Paul Passeron
Tony Allevato
Anthony Latsis
Max Desiatov
Kavon Farvardin
Tony Allevato
3405691582
Doug Gregor
Alexis Laferrière
Ben Langmuir
Allan Shortlidge
Steven Wu
Jonas Devlieghere
Adrian Prantl
Saleem Abdulrasool
Sameer Sundresh
Ian Anderson
Artem Chikin
Egor Zhdan
Slava Pestov
Guillaume Lessard
Kuba (Brecka) Mracek
Kushal Pisavadia
Mads Odgaard