We were enabling the `$Macros` feature unconditionally, even when the
compiler itself doesn't support macros (because it's missing
swift-syntax). Change this to only enable the feature when the
compiler supports it.
The reason why we are doing this is that:
1. For non-copyable types, switches are always at +1 for now.
2. non-copyable enums with deinits cannot be switched upon since that would
invalidate the deinit.
So deinits on non-copyable enums are just not useful at this point since you
cannot open the enum.
Once we make it so that you can bind a non-copyable enum at +0, we will
remove this check.
I added an experimental feature MoveOnlyEnumDeinits so tests that validate the
codegen/etc will still work.
rdar://101651138
I want to reserve Feature::MoveOnly only for move-only types and other
things that are part of SE-390. Other prototyped features like
noimplicitcopy and some older names for consume were left behind
as guarded by this Feature. That's really not the right way to do it,
as people will expect that the feature is enabled all the time, which
would put those unofficial features into on-by-default. So this change
introduces two new Features to guard those unofficial features.
I enabled move-only types by default, but I didn't
realize that the `Feature::MoveOnly` needs to graduate
into a `LANGUAGE_FEATURE` so that `EvaluateIfConfigCondition`
will recognize `$MoveOnly` as being true.
fixes rdar://107050387
The functionality for this flag is no longer necessary because the emit module jobs for deprecated architectures no longer use an artificially low deployment target.
Resolves rdar://104758113
LLVM's `CASReference.h` uses `assert()` without first including `<cassert>`,
which poses a problem here when `CASReference.h` is included first thing in a
submodule.
In FreeBSD's <assert.h>, `assert()` expands to a call to a function that is
declared within header guards. That is, only the first include of `<assert.h>`
gets the function declaration.
This is module-unfriendly, since it means that if multiple submodules of a
module both include `<assert.h>`, only one of them ends up with a usable
`assert()` macro. If you haven't (transitively) included the right submodule,
and you haven't included `<assert.h>` yourself, then you get a compile error
that looks like the following:
```
llvm-project/llvm/include/llvm/CAS/CASReference.h:75:5: error: declaration of '__assert' must be imported from module 'LLVM_Utils.Support.MathExtras' before it is required
assert(InternalRef != getDenseMapEmptyRef() && "Reserved for DenseMapInfo");
/usr/include/assert.h:77:6: note: declaration here is not visible
void __assert(const char *, const char *, int, const char *) __dead2;
swift/include/swift/AST/DeclContext.h:31:10: error: could not build module 'BasicBridging'
#include "swift/Basic/SourceLoc.h"
swift/SwiftCompilerSources/Sources/Basic/SourceLoc.swift:13:8: error: could not build C module 'ASTBridging'
import ASTBridging
```
Ideally `CASReference.h` would include `<cassert>` itself. But use of
`assert()` without a prior include of `<cassert>` is common in LLVM. It's even
encouraged by the LLVM "coding standards", which say:
> Use the “assert” macro to its fullest. [...] The “<cassert>” header file is
> probably already included by the header files you are using, so it doesn’t
> cost anything to use it.
Since the include of `CASReference.h` appears to be a temporary workaround, add
to it by including `<cassert>`, too.
* [IRGen] Add layout strings for generic and resilient types
rdar://105837048
* Add some corner cases
* Add flag to enable generic instantiation and some fixes
* Fix resilient types
* Fix metadata accessor function pointers in combined layout strings
Once the API has gone through Swift Evolution, we will want to implicitly
import the _Backtracing module. Add code to do that, but set it to off
by default for now.
rdar://105394140
We're going to move toward the new swift-syntax formatter. Use it for
the "swift" diagnostic style instead of the experimental formatter
written in C++.
There are some tests for the experimental formatter in C++ that test
precise formatting of diagnostics. I've disabled them in the same
places where the new swift-syntax formatter is enabled, for now. We
may choose to remove them entirely, because swift-syntax itself is
where the specific format is defined, and has those same kinds of
tests already.
Add '-validate-clang-modules-once' and '-clang-build-session-file' corresponding to Clang's '-fmodules-validate-once-per-build-session' and '-fbuild-session-file='. Ensure they are propagated to module interface build sub-invocations.
We require these to be first-class Swift options in order to ensure they are propagated to both: ClangImporter and implicit interface build compiler sub-invocations.
Compiler portion of rdar://105982120
rdar://105837040
* WIP: Store layout string in type metadata
* WIP: More cases working
* WIP: Layout strings almost working
* Add layout string pointer to struct metadata
* Fetch bytecode layout strings from metadata in runtime
* More efficient bytecode layout
* Add support for interpreted generics in layout strings
* Layout string instantiation, take and more
* Remove duplicate information from layout strings
* Include size of previous object in next objects offset to reduce number of increments at runtime
* Add support for existentials
* Build type layout strings with StructBuilder to support target sizes and metadata pointers
* Add support for resilient types
* Properly cache layout strings in compiler
* Generic resilient types working
* Non-generic resilient types working
* Instantiate resilient type in layout when possible
* Fix a few issues around alignment and signing
* Disable generics, fix static alignment
* Fix MultiPayloadEnum size when no extra tag is necessary
* Fixes after rebase
* Cleanup
* Fix most tests
* Fix objcImplementattion and non-Darwin builds
* Fix BytecodeLayouts on non-Darwin
* Fix Linux build
* Fix sizes in linux tests
* Sign layout string pointers
* Use nullptr instead of debug value
Executable compiler plugins are programs invoked by the host compiler
and communicate with the host with IPC via standard IO (stdin/stdout.)
Each message is serialized in JSON, prefixed with a header which is a
64bit little-endian integer indicating the size of the message.
* Basic/ExecuteWithPipe: External program invocation. Lik
llvm::sys::ExecuteNoWait() but establishing pipes to the child's
stdin/stdout
* Basic/Sandbox: Sandboxed execution helper. Create command line
arguments to be executed in sandbox environment (similar to SwiftPM's
pluging sandbox)
* AST/PluginRepository: ASTContext independent plugin manager
* ASTGen/PluginHost: Communication with the plugin. Messages are
serialized by ASTGen/LLVMJSON
rdar://101508815
This will be enabled by default in Swift 6, but can now also be enabled by passing `-enable-upcoming-feature DisableActorInferenceFromPropertyWrapperUsage` to the compiler.
