Controlled with a new flag '-direct-clang-cc1-module-build'
This will allow clients to formulate 'swift-frontend' invocations with fully-specified set of cc1 arguments (using '-Xcc -Xclang -Xcc <FLAG>') required for the PCM build, without having to go through the driver.
* [SILOptimizer] Add prespecialization for arbitray reference types
* Fix benchmark Package.swift
* Move SimpleArray to utils
* Fix multiple indirect result case
* Remove leftover code from previous attempt
* Fix test after rebase
* Move code to compute type replacements to SpecializedFunction
* Fix ownership when OSSA is enabled
* Fixes after rebase
* Changes after rebasing
* Add feature flag for layout pre-specialization
* Fix pre_specialize-macos.swift
* Add compiler flag to benchmark build
* Fix benchmark SwiftPM flags
This includes:
- bumping the SWIFT_SYMBOLGRAPH_FORMAT_MINOR version
- introduction of the "swift.extension" symbol and "extensionTo" relationship
- adding support for ExtensionDecl to the Symbol class
- adding a "typeKind" field to the symbol's extension mixin which indicates what kind
of symbol was extended
- intoduction of the -emit-extension-block-symbols flag, which enables the behavior
outlined below
- adaptions to SymbolGraphASTWalker that ensure a swift.extension symbol is emitted
for each extension to a type that does not exist in the local symbol graph
- adaptions to SymbolGraph and SymbolGraphASTWalker that ensure member and conformance
relationships are correctly associated with the swift.extension symbol instead of
the original type declaration's (extended nominal's) symbol where applicable
- adaptions to SymbolGraphASTWalker that ensure swift.extension symbols are connected
to their respective extended nominal's symbol using an extensionTo relationship
Testing:
- adds SymbolGraph tests that test behavior only relevant in
-emit-extension-block-symbols mode
- adapts some SymbolGraph tests to additionally test similar behavior for
extensions to external types in -emit-extension-block-symbols mode
- adapts some SymbolGraph tests to (additionally or exclusively) test the
behavior with -emit-extension-block-symbols mode enabled
Bugfixes:
- fixes a bug where some conformsTo relationships implicated by the conformances
declared on an extension to an external type were not emitted
(see test/SymbolGraph/Relationships/ConformsTo/Indirect.swift)
Further changes:
- documents the strategy for naming and associating children declared in extensions
to typealiases (see test/SymbolGraph/Relationships/MemberOf/Typealias.swift,
test/SymbolGraph/Symbols/Names.swift)
Let's not print the -experimental-spi-only-imports flag in the
swiftinterface and always consider it available there. This is a more
backwards and forwards compatible way to handle swiftinterfaces
evolution.
Various clients still use the old driver to convert a driver arguments to frontend arguments. This has to work when given new driver arguments, ie. not fail with an unknown argument error.
Move all "extra options" from the new driver into `Options.td` and mark them as new driver only.
This makes sure that when Swift is generating a `.swiftinterface` file for a Swift module with a dependency on C++ module, `-enable-experimental-cxx-interop` is emitted under `// swift-module-flags:`.
The module interface might refer to C++ symbols which are not available in Swift without C++ interop enabled. This caused a build error for Swift LLVM bindings during `verify-module-interface` stage: Swift tried to import the module interface and couldn't find C++ stdlib headers because C++ interop was disabled.
Adds frontend option -enable-stack-protector to enable emission of a
stack protector.
Disabled by default.
When enabled enables LLVM's strong stack protection mode.
rdar://93677524
I am separating the concern of weakly linking symbols that are introduced at the deployment target from the concern of type checking this new type of potential unavailability.
Resolves rdar://97925900
Put pointers to class_ro_t referenced from generic class patterns in a section __swift_rodatas such that they are discoverable by the linker.
The linker can then make the method lists contained in the class_ro_t relative like it can for objective c class metadata from non-generic swift classes.
rdar://66634459
This flag is required in the driver to eg. choose `clang` vs `clang++`
for the linker. Move it back to a driver option and hide both it and the
stdlib flag from help.
This was already enabled as part of `-enable-implicit-dynamic` but this
new flag allows turning on opaque type erasure all by itself whether or
not `dynamic` is added explicitly.
rdar://97375478
Introduce the `-enable-upcoming-feature X` command-line argument to
allow one to opt into features that will be enabled in an upcoming language
mode. Stage in several features this way (`ConciseMagicFile`,
`ForwardTrailingClosures`, `BareSlashRegexLiterals`).
Defined SWIFT_STDLIB_TASK_TO_THREAD_MODEL_CONCURRENCY to describe
whether the standard library will use the task-to-thread model for
concurrency. It is true only for freestanding non-Darwin stdlibs.
When it is true, SWIFT_CONCURRENCY_TASK_TO_THREAD_MODEL is defined
during stdlib compilation of both Swift and C++ sources.
Added an option to LangOptions to specify which concurrency model is
used, either standard or task-to-thread. When
SWIFT_STDLIB_TASK_TO_THREAD_MODEL_CONCURRENCY is true, the model is
specified to be task-to-thread.
When developing a module for an OS or SDK, one may use declarations from other modules that were recently introduced in the in-development OS. Those declarations will be annotated as available at the deployment target of the client module and yet the symbols for that declaration are not available in all development builds of that OS. If the module strongly links those symbols, it will crash on older development builds of the OS. The `-enable-experimental-ad-hoc-availability` flag is designed to give developers the option of weakly linking all symbols in other modules that were introduced at the deployment target.
This change introduces the basic change in linking behavior but does not address typechecking. Use of the declarations that are made unavailable in this mode will need to be diagnosed and developers will need a way to detect the unavailability at runtime before use.
Resolves rdar://96011550
So far, static arrays had to be put into a writable section, because the isa pointer and the (immortal) ref count field were initialized dynamically at the first use of such an array.
But with a new runtime library, which exports the symbols for the (immortal) ref count field and the isa pointer, it's possible to put the whole array into a read-only section. I.e. make it a constant global.
rdar://94185998
This reverts the revert commit df353ff3c0.
Also, I added a frontend option to disable this optimization: `-disable-readonly-static-objects`
