This improves upon the existing documentation to provide a clearer end-to-end
workflow for new contributors and people who wish to build the toolchain
locally but do not intend to submit patches.
We also provide more directions for systematically utilizing our existing
documentation.
- Sort the arguments to CMake to make them easier to spot
- Sort the clones to be in order of use
- Use shorter build directory names as the paths can be troublesome
- Update instructions all the way through to swift-package-manager as that now works
- Fix instructions for cloning swift-llbuild (the repository contains symlinks)
- Add instructions for new swift-package-manager dependencies
- Homogenise the build rules (they are at this point, largely copy-paste from each one, just listing dependencies)
- Switch `swift-llbuild` to use `clang-cl` instead of `cl` and add a workaround for code splitting
A previous PR collected the various existential types into a single
section of the document.
This PR takes advantage of that structure to clarify the discussion of existential and protocol casting:
* Adds a general discussion of existential casting
* Introduces the "strong existential invariant" and "weak existential invariant" that are common to all existential types
* Makes a more precise distinction between protocols and existential types
This last point involves a number of careful wording nuances based on the following:
* A "protocol" is a syntactic construct defining a collection of requirements and default implementations (the latter via "protocol extensions")
* Some protocol definitions (those without associated types or `Self` references) have an associated "protocol witness" existential type
* A protocol witness existential type has the same name as the protocol definition from which it is derived but they are conceptually different notions
* Existential types such as `Any`, `AnyObject`, and `Error` are not protocols -- for example, they cannot be extended.
* `AnyHashable` is a type-erased container type but is not an existential. It does however behave like an existential for casting purposes.
Only general intro and the "Relative Pointers" section are added to get started. More sections to be added in the future after preliminary feedback on this document is gathered.
Related to SR-9307
This only rearranges the existing sections; it does not change any technical points.
This attempts to make the spec a little clearer by grouping the individual type discussions under four main headings:
* Classes and Foreign Types. This includes Swift classes, Obj-C classes, and CF types.
* Other Concrete Types. Struct, Enum, Tuple, Function, Optional, and Set/Dict/Array
* Existential Types. Any, AnyObject, Error, Protocol types, and AnyHashable(*)
* Metatypes & Existential Metatypes (*)
This organization seems to flow a little better.
In particular, it gives me a place to discuss issues common to all Existential types, which I'll work through in a subsequent PR.
Footnotes: This organization isn't perfect, of course:
* AnyHashable isn't really an Existential type, but it behaves as such for casting purposes, so it makes the most sense to discuss it in the Existentials section.
* Metatypes are technically concrete types, but it seems to make more sense to discuss them after discussing Existential types.
* AnyObject behaves as if every class type implicitly conformed to it as a protocol.
* Protocols "inherit" from other protocols, and this has implications for casting to existential metatypes
I also moved the Any self-conformance invariant
to the self-conformance subsection and added a
couple of explanatory sentences.
A specification for Swift's dynamic casting operations.
This specification tries to reflect the _intent_ of the current implementation, defining a consistent behavior that reflects as far as possible the behavior of the current implementation. Deviations from this specification will generally be treated as bugs in the current implementation.
This is a roll-forward of https://github.com/apple/swift/pull/32950, with explicit c++17 version removed from tests. This is not needed since C++17 is the default anyway.
--
In this PR we teach `ClangImporter` to import typedef statements with template instantiation as its underlying type.
```c++
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
typedef MagicWrapper<MagicNumber> WrappedMagicNumber;
```
will be made available in Swift as if `WrappedMagicNumber` is a regular struct.
In C++, multiple distinct typedeffed instantiations resolve to the same canonical type. We implement this by creating a hidden intermediate struct that typedef aliasses.
The struct is named as `__CxxTemplateInst` plus Itanium mangled type of the instantiation. For the example above the name of the hidden struct is `__CxxTemplateInst12MagicWrapperI11MagicNumberE`. Double underscore (denoting a reserved C++ identifier) is used to discourage direct usage. We chose Itanium mangling scheme because it produces valid Swift identifiers and covers all C++ edge cases.
Imported module interface of the example above:
```swift
struct __CxxTemplateInst12MagicWrapperI11MagicNumberE {
var t: MagicNumber
}
struct MagicNumber {}
typealias WrappedMagicNumber = __CxxTemplateInst12MagicWrapperI11MagicNumberE
```
We modified the `SwiftLookupTable` logic to show hidden structs in `swift_ide_test` for convenience.
Co-authored-by: Rosica Dejanovska <rosica@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Robert Widmann <devteam.codafi@gmail.com>
In this PR we teach `ClangImporter` to import typedef statements with template instantiation as its underlying type.
```c++
template<class T>
struct MagicWrapper {
T t;
};
struct MagicNumber {};
typedef MagicWrapper<MagicNumber> WrappedMagicNumber;
```
will be made available in Swift as if `WrappedMagicNumber` is a regular struct.
In C++, multiple distinct typedeffed instantiations resolve to the same canonical type. We implement this by creating a hidden intermediate struct that typedef aliasses.
The struct is named as `__CxxTemplateInst` plus Itanium mangled type of the instantiation. For the example above the name of the hidden struct is `__CxxTemplateInst12MagicWrapperI11MagicNumberE`. Double underscore (denoting a reserved C++ identifier) is used to discourage direct usage. We chose Itanium mangling scheme because it produces valid Swift identifiers and covers all C++ edge cases.
Imported module interface of the example above:
```swift
struct __CxxTemplateInst12MagicWrapperI11MagicNumberE {
var t: MagicNumber
}
struct MagicNumber {}
typealias WrappedMagicNumber = __CxxTemplateInst12MagicWrapperI11MagicNumberE
```
We modified the `SwiftLookupTable` logic to show hidden structs in `swift_ide_test` for convenience.
Resolves https://bugs.swift.org/browse/SR-12591.
Co-authored-by: Rosica Dejanovska <rosica@google.com>
Co-authored-by: Dmitri Gribenko <gribozavr@gmail.com>
Co-authored-by: Robert Widmann <devteam.codafi@gmail.com>
* [Mangling] Add a new mangling to represent opaque return type for ObjC runtime name
* [Docs] Add the new 'Qu' mangling to 'Mangling.rst' document
* [Test] Update test invocation arguments
Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
Make `Optional` conditionally conform to `Differentiable` when the `Wrapped` type does.
`Optional.TangentVector` is a wrapper around `Wrapped.TangentVector?`.
Also, fix `Array.TangentVector.zeroTangentVectorInitializer`.
Resolves TF-1301.
