We would previously fail to deserialise the IsStaticLibrary bit on
certain declarations when they were imported implicitly. This would
result in incorrect IRGen on Windows when building against a static
swift module.
Attribute @_silgen_name is today only allowed to be used on functions, this change allows usage on globals as well. The motivation for that is to be able to "forward declare" globals just like it's today possible to do with functions (for the cases where it's not practical or convenient to use a bridging header).
Separately, this change also adds a @_silgen_name(raw: ...) syntax, which simply avoids mangling the name (by using the \01 name prefix that LLVM uses). The motivation for that is to be able to reference the "magic Darwin linker symbols" that can be used to look up section bounds (in the current dylib/module) -- those symbols don't use the underscore prefix in their mangled names.
The `bare` attribute indicates that the object header is not used throughout the lifetime of the value.
This means, no reference counting operations are performed on the object and its metadata is not used.
The header of bare objects doesn't need to be initialized.
The `bare` attribute indicates that the object header is not used throughout the lifetime of the object.
This means, no reference counting operations are performed on the object and its metadata is not used.
The header of bare objects doesn't need to be initialized.
SelectEnumInstBase will be templated in the next commit.
Instead of using templated SelectEnumInstBase everywhere, introduce
a new wrapper type SelectEnumOperation.
Unlike `swift-frontend -scan-dependencies` option, when dependency
scanner is used as a library by swift driver, the SwiftScanningService
is shared for multiple driver invocations. It can't keep states (like
common file dependencies) that can change from one invocation to
another.
Instead, the clang/SDK file dependencies are computed from each driver
invocations to avoid out-of-date information when scanning service is
reused.
The test case for a shared Service will be added to swift-driver repo
since there is no tool to test it within swift compiler.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
'load-plugin-library', 'load-plugin-executable', '-plugin-path' and
'-external-plugin-path' should be searched in the order they are
specified in the arguments.
Previously, for example '-plugin-path' used to precede
'-external-plugin-path' regardless of the position in the arguments.
Teach swift dependency scanner to use CAS to capture the full dependencies for a build and construct build commands with immutable inputs from CAS.
This allows swift compilation caching using CAS.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
The `hasStorage()` computation is used in many places to determine the
signatures of other declarations. It currently needs to expand accessor
macros, which causes a number of cyclic references. Provide a
simplified request to determine `hasStorage` without expanding or
resolving macros, breaking a common pattern of cycles when using
macros.
Fixes rdar://109668383.
This PR makes diagnostics on deserialization errors caused by project
configuration more helpful by providing contextual information on the
issue:
- Path to the modules involved (up to 4 modules): the loaded swiftmodule
with the broken outgoing reference, the path to the module where the
decl was expected, the path to the underlying clang module, and the path
to the module where the decl was found. This information should prevent
us from having to ask for a different log with `-Rmodule-loading`.
- Hint to delete the swiftmodule files when the module is
library-evolution enabled.
- Hint that clang settings affect clang modules involved in this
scenario.
- Pointing out when a decl moved between two modules with a similar name
(where one name is a prefix of the other). This is a common issue when
headers are shared between a clang framework's public and private
modules.
- Pointing out layering issues when an SDK module imports a local
module.
- Pointing out Swift language version mismatch which may lead to the
compiler viewing the same clang decls differently when they are modified
by APINotes files.
This instruction is similar to AssignByWrapperInst, but instead of having
a destination operand, the initialization is fully factored into the init
function operand. Like AssignByWrapper, AssignOrInit has partial application
operands of both the initializer and the setter, and DI will lower the
instruction to a call based on whether the assignment is initialization or
a setter call.
