The attached and freestanding macro attributes use the same parsing
logic and representation, so generalize the "attached" attribute into
a more general "macro role" attribute.
* Move Runtime into _Runtime
Fix more _Runtime names
* Add availability to all API
* Build _Runtime and Reflection modules
* Use threading's mutex for all platforms
add stdlib include
Update `build-windows-toolchain.bat` to build IndexStoreDB statically.
This is used in exactly one location: SourceKit-LSP. By statically
linking the product we reduce the distribution set and reduce the disk
size by ~50K.
Dynamic:
629,248 IndexStoreDB.dll
8,943,616 sourcekit-lsp.exe
Static:
9,523,200 sourcekit-lsp.exe
Describe attached macros with the `@attached` attribute, providing the
macro role and affected names as arguments to the macro. The form of
this macro will remain the same as it gains other kinds of attached
macro roles beyond "accessor".
Remove the "accessors" role from `@declaration`, which will be going
away.
Missed this when I originally added the
`--lit-jobs` build-script option, propagate the value
provided to `LLVM_LIT_ARGS` in addition to
`SWIFT_LIT_ARGS`.
Add support for freestanding declaration macros.
- Parse `@declaration` attribute.
- Type check and expand `MacroExpansionDecl`.
Known issues:
- Generic macros are not yet handled.
- Expansion does not work when the parent decl context is `BraceStmt`. Need to parse freestanding declaration macro expansions in `BraceStmt` as `MacroExpansionDecl`, and add expanded decls to name lookup.
While clang and the build-system can now handle generating
Catalysit-supporting executables, the OSS swift-frontend is missing
something.
This is failing in:
SILGen/availability_query_maccatalyst_zippered_canonical_versions.swift
The compiler is only emitting the availability check-info for the macOS
target, not the iOS target.
e.g. for the following snippet
```
if #available(OSX 10.16, iOS 51.1.2, *) {
}
```
We end up emitting the literal checks for
integer_literal $Builtin.Word, 10
integer_literal $Builtin.Word, 16
integer_literal $Builtin.Word, 0
but we're missing
integer_literal $Builtin.Word, 51
integer_literal $Builtin.Word, 1
integer_literal $Builtin.Word, 2
This would be a most unfortunate miscompile.
Using single-threaded concurrency was a temporary solution, now that the task-to-thread model actually supports multiple threads, let's switch off of it. Instead, let's introduce a "global executor none" option (implicitly set under the task-to-thread model) to denote that the concurrency model is not using a global executor.
rdar://99448771
Windows now partially supports static linking of Swift libraries
(non-swiftCore targets). Use this to enable static linking of Yams as
there is a single user (swift-driver). This allows us to save ~256KB
due to the internalisation.
The fix prevents errors like this:
```
Collecting frameworks from macOS b'13.0' at b'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk'
Traceback (most recent call last):
File "./swift-api-dump.py", line 360, in <module>
main()
File "./swift-api-dump.py", line 346, in main
jobs = jobs + create_dump_module_api_args(
File "./swift-api-dump.py", line 265, in create_dump_module_api_args
(frameworks, sdk_root) = collect_frameworks(sdk)
File "./swift-api-dump.py", line 246, in collect_frameworks
for entry in os.listdir(frameworks_dir):
FileNotFoundError: [Errno 2] No such file or directory: "b'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk'/System/Library/Frameworks"
```
Resolves rdar://100295474.
