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.
This fixes an issue if the range ends with a string literal that contains the IDE inspection target. In that case the end of the range will point to the start of the string literal but the IDE inspection target is inside the string literal and thus after the range’s end.
Macro expansion buffers, along with other generated source buffers,
need more precise "original source ranges" that can be had with the
token-based `SourceRange`. Switch over to `CharSourceRange` and provide
more thoughtfully-determined original source ranges.
